Redesign ProducerJob extension of Job

[elizarov]

In the current design produce coroutine builder returns an instance of ProducerJob interface that extends ReceiveChannel and Job interfaces. The former gives access to all the channel operations, while the later contains Job-management API. Unfortunately, the Job is a CoroutineContext.Element and has operations like fold that operate on coroutine contexts. It clashes with the proposed extensions on ReceiveChannel that treats it as a sequence of elements with fold on them having a different meaning. See discussion in #88 for details.

So the proposal is deprecate ProducerJob and replace it with Producer interface that is a ReceiveChannel (to enable convenient pipelining) and has job as a property for cases where it is needed.

Now, the most common use-case for which you might need to access a producer's job is to cancel it when you don't need it. To make it easier, the proposal is to add cancel operation on ReceiveChannel interface directly. The semantics of cancel for a ReceiveChannel if that it signals that no more elements are going to be received from this channel and the producer of the channel must abort if it is still running (send will throw CancellationException). All the built-in pipelining operations like filter, map, etc on ReceiveChannel (see #88) are going to always cancel the receive channel when they are done (even if they crash), so this way an operational pipeline that starts with produce { ... } and continues with one of those pipelining operations will always cancel the producer without a risk of a producer leak if something crashes downstream.

[fvasco]

Analogously to Java's Channel and Reactive Streams maybe we should introduce a Disposable interface.

What is the purpose of job attribute in case of a plain Channel?
Is the above proposed interface enough?

[elizarov]

We will not have job on a plain channel. Only Producer will have it, since it is produced by a single coroutine. However, the is an alternative design where every channel has a producer job whose life-time is bound to the channel's life-time and this job is cancelled when the channel is closed.

[fvasco]

I looked better,
ReceiveChannel should implement the DisposableHandle, in such case becomes valid:

job.disposeOnCompletion(channel)

More in genera: Job and Channel are both disposable, so might be helpful review some design choices about "Disposable" interface.