Re: draft Carrier API

Hi Doug,

> On 7 Mar 2020, at 16:29, Doug Lea via Concurrency-interest <[email protected]> wrote:
> 
> 
> Collecting replies/responses, with updated sketches pasted below and at
> https://urldefense.com/v3/__http://gee.cs.oswego.edu/dl/wwwtmp/Carrier.java__;!!GqivPVa7Brio!PZhOkwHJkZRpKSYlBvCwjh6FFuBxTE1YQ5rgYjx4FGbnzfnK03nLFEHaW0lIbt8_SvE$ 


This latest version looks like it is headed in the right direction.

Just a few questions / clarifications around closing:

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 )?   I assume the `onClose` CF will receive this cause too?

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? Oops...
   now I ask myself will async-close result in ClosedException, or
   interrupt of waiters?
   
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?

-Chris.
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest