[concurrency-interest] draft Carrier API

[Doug Lea]

On 3/9/20 10:49 AM, Chris Hegarty via Concurrency-interest wrote:

> 
> 1) closeExceptionally - what effect will the passed `cause` Throwable
>    have on other methods, say, like receive? Will the passed `cause` be
>    the cause of the ClosedException ( thrown from a thread blocked in
>    receive )?  

Yes. To be clearer, method getCloseException  should be renamed
getCloseCause (returning null if non-exceptional).

>  I assume the `onClose` CF will receive this cause too?

The CF holds "this" so can be accessed.

> 
> 2) ClosedException is an IllegalStateException - Ok. If the OnInterrupt
>    policy is `CLOSE`, then a thread already blocked in a receive
>    invocation will throw ClosedException - same as it would if the
>    carrier was already closed before the receive invocation. Receiving
>    an IllegalStateException for an interrupt seems a little odd to me
>    for this case (but maybe that is ok). Given this, then it is not
>    possible to discern the difference between a carrier that was closed
>    prior to receive or if receive was interrupted.  Hmm... maybe this is
>    the point - consistent behavior in the face of async-close? 

Right.
>    now I ask myself will async-close result in ClosedException, or
>    interrupt of waiters?
Abrupt closes always interrupt blocked threads, and even under "IGNORE"
policy will cause them to throw ClosedException. (This is one of several
reasons for policy-based interrupt handling.)

>    
> 3) Should all carriers be, in effect, closeable? What would be the
>    affect of Carrier.discardingCarrier().close(). Should this carrier be
>    effectively uncloseable, so there could be a singleton instance?

Not sure.  It's analogous to the ForkJoinPool.commonPool, that just
ignores shutdown, in explicit violation of ExecutorService spec. Which
no one complains about. The same could be done here. I suppose that the
spec for close could be phrased in a way that allows "permanent"
entities to ignore close.

-Doug