dev@grizzly.java.net

Re: [Proposal] SelectionKey Management

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 21 Aug 2007 13:49:40 -0400

Hi Charlie,

charlie hunt wrote:
> One of the major problems I have in the current implementation of the
> Controller.doSelect() is the following set of code:
>
> readyKeys = selectorHandler.keys();
> if (readyKeys.isEmpty()){
> return;
> }
>
> if (selectorHandler.isOpen()) {
> selectionKeyHandler.expire(readyKeys.iterator());
> }
>
>
> IMO, we are assuming with the above logic that every application that
> uses a Grizzly Controller will be doing the expiring of SelectionKeys.
> I don't think we should make that assumption in the Controller. Granted
> if the readKeys is empty or the SelectionKeyHandler.expire() method is
> empty, no expiring of keys happens. But, you have some unnecessary
> logic executing here that from a design standpoint for applications that
> do not need to expire keys will execute.
>
> I think the above logic needs to get moved to the default tcp
> SelectorHandler.postSelect() since what I think what we really want is
> to make the expiring of SelectionKeys a plug-able component.
>
> Isn't expiring of SelectionKeys really a "post select" activity as
> opposed to a "do select" activity? And, shouldn't it be the
> SelectorHandler that decides what the "post select" activity should be,
> if any?

I see. I agree with your point. I will make the appropriate changes :-) :-)

Thanks!

-- Jeanfrancois



>
> charlie ....
>
> Jeanfrancois Arcand wrote:
>> Hi,
>>
>> reading Charlie and Alexey discussion on how the SelectionKey
>> management code, I came with the following API changes in order to fix
>> the issues Charlie as pointed out. I've deprecated both
>> SelectionKeyHandler register/expire and added two new method. Those
>> two methods will allow the complete removal of the expiring code that
>> was by default added to the TCPSelectorHandler.
>>
>> See my last commit for the details. Please let me know what you think.
>> I can can revert the changes in case we are in disagreement :-)
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net