CompletionHandler should take the channel too
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
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:
>> 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 ?
More information about the nio-dev