[concurrency-interest] draft Carrier API

[Chris Hegarty]

Thanks Doug, all sounds good to me.

-Chris.

> On 10 Mar 2020, at 10:41, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> 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
> 
> 
>