Re: draft Carrier API
Doug Lea via Concurrency-interest <[email protected]> Tue, 10 Mar 2020 06:41:07 -0400
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest