Re: draft Carrier API

I think it may be useful to clarify who is meant to call each of the close
methods.

Eg is it receiver calling closeForSending to stop an inundation, and sender
closeForReceiving to signal end of stream? Maybe senderDone / receiverDone
or some better name can help.

Also, it is not clear how the receive for a stream with no more items is
meant to behave. Sender closes its end, the receiver blocks when empty. Or
throws? That seems like the only way out, but seems really weird. A bit
like python throwing StopIterationException.

Alex

On Sun, 8 Mar 2020, 11:55 Doug Lea, <[email protected]> wrote:

> On 3/7/20 6:25 PM, Alex Otenko wrote:
> > Send is declared to throw when is closed for sending. Is there a good
> > reason to not throw when is closed for receiving? Or what is the
> > intended behavior in this case, given that it may block if full?
> >
>
> Normally, a completed receiver should invoke (bidirectional) close.
> Calling closeForReceiving provides more flexibility, but with more cases
> for users to consider (like stuck senders).
>
> But this question invites considering whether even having
> closeForReceiving would lead to more errors than correct usages.
> Considering that some of the motivation for Carrier is to reduce
> opportunities for errors people encounter with hand-made components
> built from BlockingQueues etc, I think we could remove it.
>
> -Doug
>
>
>

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