[concurrency-interest] draft Carrier API
Chris Hegarty
chris.hegarty at oracle.com
Mon Mar 9 14:49:00 UTC 2020
Hi Doug,
> On 7 Mar 2020, at 16:29, Doug Lea via Concurrency-interest <concurrency-interest at cs.oswego.edu> 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.
More information about the loom-dev
mailing list