[concurrency-interest] draft Carrier API

Alex Otenko oleksandr.otenko at gmail.com
Sun Mar 8 08:49:27 EDT 2020

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

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.


On Sun, 8 Mar 2020, 11:55 Doug Lea, <dl at cs.oswego.edu> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20200308/e4b2c718/attachment.htm>

More information about the Concurrency-interest mailing list