[concurrency-interest] draft Carrier API

[Alex Otenko]

IllegalStateException is ok if receiver should've known there are no more
items to receive. This is a good idea in cases with definite length of
stream, and the length being known to the receiver before entering
receive(). This doesn't seem like a good idea for indefinite length cases -
like, loop to read all items until eof.

If you use exceptions to signal eof, neat loops turn into a cludge of an
infinite loop with try-catch and a break inside, messing up scopes in the
process.

Neat loop:
for(Optional<T> x = carrier.receive(); !x.isEmpty(); x = carrier.receive())
...

Ugly scope and nesting:
for(;;) {
  T x;
  try{
    x = carrier.receive();
  } catch (StopIterationException sie) {
      // did it collect the stack trace that is not needed?
      break;
  }
  ...
}

Alex

On Mon, 9 Mar 2020, 14:49 Chris Hegarty, <chris.hegarty at oracle.com> wrote:

> 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.