Deprecate produce-consume

[amitmurthy]

We currently have two different methods of inter-task communication. This issue is a reminder to deprecate the produce / consume API and have that similar functionality supported by implementing support for Channel(0), i.e., put!on a channel backed by by a 0-sized buffer will block till the time a matching take! is called.

Edit : Unbuffered channels, i.e., Channel(0) have been implemented.

[StefanKarpinski]

We may want to have a bit of a bikeshedding about what we call these operations since they are going to be the One True Inter-Task Communication method.

[tkelman]

is there any work in progress started on this?

[amitmurthy]

Not yet.

[StefanKarpinski]

Any chance of getting this done nowish?

[amitmurthy]

Will do.

[amitmurthy]

We have a couple of options here.

Option 1 : Deprecate produce, consume and Task iteration in this cycle and remove them completely in the next one. Users should use Channels for inter-task communication for this functionality by explicitly creating them and passing them across tasks.

Option 2 : Deprecate produce and consume as an API only. Support put!(t::Task=current_task(), v) and take!(t::Task=current_task()) as an alternative to existing functionality, including iteration on a Task. Each Task shall be deemed to be associated with an implicit Channel. The associated Channel is automatically closed when the task exits.

I am inclined towards the second option. Any thoughts?

[tkelman]

what kind of overhead would having an implicit channel for every task add?

[amitmurthy]

what kind of overhead would having an implicit channel for every task add?

Minimal. We would associate a Channel with a Task only when put!/take!/Task iteration is performed on a task object for the first time.

[amitmurthy]

I implemented Option 2 and was not too happy with the result. While put! and take! are a partial replacement for produce/consume, we were still left with two different means of inter-task communication. Will open a PR with option 1.

[StefanKarpinski]

What made you unhappy with the result, @amitmurthy? You didn't like the API or the implementation was messy?

[amitmurthy]

The implementation was clean. One of the stated reasons for deprecating produce/consume was to not have two different means of inter-task communication. Supporting put! and take! on Task objects negated this aim. Decided it is better to double down on Channels as the only method for inter-task communication.

Channels as an entity distinct from Tasks is Go like.
Sending and Receiving messages to/from tasks is Erlang like.

Opted for the former instead of having both.