CompletionHandler should take the channel too

Rémi Forax forax at univ-mlv.fr
Fri Apr 24 13:48:08 PDT 2009


Alan Bateman a écrit :
> Rémi Forax wrote:
>> :
>> I don't see why I have to create an ephemeral object to store a 
>> channel and a buffer
>> if the implementation already have this information but don't export it.
> I don't think we can predict all the context that the handler will 
> require when consuming the result. For some cases it may only be the 
> channel and the buffer (or buffers). In other cases it will be the 
> SSLSession or other session information. For non read/write methods 
> may be the channel and something else.
You probably misunderstand me, I haven't say that we should remove the 
attachment but
advocate for adding a parameter to all methods of the completion handler 
to give access to the channel.

I can't see a scenario where the channel is not needed. Adding this 
parameter will free the attachment
that can be used for something else, the buffer, the SSLSession, etc.
>
>>
>> Else, there is no way to find the group from an async socket channel,
>> something like:
>> asyncSocketChannel().group().shutdown();
>> should be useful.
> The reason for this is that we don't want to give out a reference to 
> the default group (because it can never be shutdown). I admit we need 
> to re-visit this but it requires special-casing the default group so 
> that it cannot be shutdown. I don't know if you read Alex and Yevgeny 
> Libman's proposal on filters but that creates the requirement to get a 
> reference to the group so that it can submit its own tasks to the 
> group's thread pool. There is merit in this proposal and the support 
> is in the implementation (but not the API yet, needs further thought).
No, I'm not aware of this proposal and was not able find a link to it.
Do you have a reference ?
>
> -Alan.

Rémi



More information about the nio-dev mailing list