7169050: (se) Selector.select slow on Solaris due to insertion of POLLREMOVE and 0 events

[Seán Coffey]

Had a look here also Alan. Looks good. I'm wondering if 
INITIAL_PENDING_UPDATE_SIZE of 64 is the optimum start size there. In 
any case, I guess a busy server won't be long arriving at the optimal 
array size.

some typos in comments :

// cancel(s) ? any pending update
// skip update if key can has cancelled
// write any reminaing updates

regards,
Sean.


On 23/05/12 14:15, Alan Bateman wrote:
> On 23/05/2012 13:46, Chris Hegarty wrote:
>> These changes look great Alan.
>>
>> One minor comment, the events are now stored as a byte. Is it ever 
>> possible to have an event that has a valid value that uses the upper 
>> order byte ( that is passed to the native short pollfd.events )? It 
>> must not be, just thought I'd ask.
> In theory it should be a short[] but that takes up too much memory 
> when a fd limit of 64k or higher. A byte works for us because the 
> values of POLLIN and POLLOUT fit without any shifting or mapping. So 
> thanks for reviewing, this resolves a long standing performance issue.
>
> -Alan.