[concurrency-interest] draft Carrier API
chris.hegarty at oracle.com
Tue Mar 10 06:45:25 EDT 2020
Thanks Doug, all sounds good to me.
> 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?
>> 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.
More information about the Concurrency-interest