Re: draft Carrier API

> On 11 Mar 2020, at 05:00, John Rose <[email protected]> wrote:
> 
> On Mar 8, 2020, at 6:37 AM, Doug Lea <[email protected]> wrote:
>> 
>> interface CarrierSender<T> extends Carriable<T> {
>>   void finishSending();           // disable sending; close when empty
>>   // ...
>> }
> 
> This rings true to me (but I’m not an expert in these APIs).
> 
> Would there be a use case where the sender side of a connection
> is the subject of a try-with-resources, where the end of the block
> needs to issue a `finishSending` call?  In that case, the sender
> side (in isolation from the whole channel) might benefit from
> a view object whose close method is an alias for `finishSending`.


Yeah, I was going to ask something similar, about how we see common
usage of senders. I suspect that a lot (the majority?) of folk will
want orderly shutdown on the sender-side, so will invoke
`shutdownSending`, which first disables further sending, and secondly
closes when empty.

For scenarios where the receiver and sender do not have intimate or
direct knowledge of each other, then I'm not sure if it makes all that
much sense to use a try-with-resources on the sender side - unless it is
being used as an abort mechanism if orderly-close has not been completed
by the end of the try-with-resources block.

If we think that orderly-close will be more common that abortive-close,
then it could be made the default, and an explicit method added to
CarrierSender for abortive-close. This would more easily facilitate the
use within try-with-resources blocks - but of course the resource is not
really "freed", that depends on a well-behaved receiver. I don't think
that this would have any adverse negative affect on the receiver.

-Chris.

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