dev@grizzly.java.net

Re: [Proposal] SelectionKey Management

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

charlie hunt wrote:
> Jeanfrancois Arcand wrote:
>> 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
>> :-) :-)
>
> I considered making the changes while you on vacation, (catching [big]
> trout, etc) ;-)
>
> But, I was fearful it might break existing Grizzly based applications.
>
> Thought it made sense til you got back and we (Grizzly community) had a
> discussion about it first. :-)

Done :-) Now you need to review :-)

Thanks

-- Jeanfrancois


>
> charlie ....
>
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> 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