hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: svn commit: r724147
Date Wed, 10 Dec 2008 22:55:08 GMT
Sam Berlin wrote:
>> Good catch. My bad. I re-introduced the critical section around interestOps
>> and made interestOps volatile. Please review [1]
>>
>> The reason I have done this change is to make it possible for the I/O
>> session to defer mutation of SelectionKey's interestOps to the I/O dispatch
>> in order to avoid the dead-lock condition described in HTTPCORE-155 [2] when
>> running on buggy JREs such as IBM's
> 
> I'm not positive the changes (or those in r724457) will do anything to
> resolve the issue on the IBM JREs.  The issue is caused by very poor
> javadoc recommendations on SelectionKey -- as Marc pointed out, "...
> In a naive implementation, reading or writing the interest set may
> block indefinitely if a selection operation is already in progress".
> In a nutshell, this means that if the selector is blocked on a
> select(), it is impossible to tell it ask a SelectionKey to change its
> interest.  This makes no sense in a high-performing NIO application,
> as interest changes can happen from any thread and selector.wakeup()
> tells the selecting-thread to take a new look at the interest.
> 
> I think the code as it is now (with r724457) will actually hinder
> speed in the already-working case and be ineffective in the
> not-working case.  (That said, they won't break the already-working
> case.)  This is because there's no an additional mutex required for
> changing interestOps -- the local one and the one implicitly gotten
> when calling setInterestOps on a SelectionKey.
> 
> There's a few approaches that can help the IBM JRE case.  One, which
> might not work all the time, but should work fairly reliably, would be
> to call selector.wakeup() prior to grabbing the SelectionKey's mutex.
> You'll still need to call selector.wakeup() after setting the ops,
> though, because of the problem with the approach.  The selector may
> wakeup & reselect before the ops are actually set.  In Sun's case,
> this would just be a temporary problem -- the additional wakeup()
> afterwards will fix things.  In IBM's case, it would lead right back
> to the deadlock.
> 
> The other approach would be to somehow pass the requested ops into the
> selecting thread & have the thread calling select() set the interest
> ops.  This can be done by storing the ops locally, telling the
> selector to wakeup, and having the selecting thread iterate through
> all of it's channels prior to the next select and resetting the
> interestOps before selecting.  That should fix the problem on all
> JREs, but may be architecturally difficult.
> 


Hi Sam,

These changes were not meant to resolve the issue, but rather make it 
easier to override the way interestOps were manipulated by IOSession 
implementations. I am sorry if I failed to make that clear.

Anyways, reverted the changes for now. Let's revisit the issue in the 
course of 4.1 development.

> (Sorry for the delay in responding... been working furiously to
> release an alpha version of LimeWire 5, now finally released.)
> 
> Sam

Many thanks for reviewing the changes and congrats for the release.

Cheers

Oleg


> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message