I can add the comments into the code, but I looked at the SocketIoProcessor
class in the trunk, and the code is a little different. There is no call to
selector.close(). Approx line 510.
On 7/28/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
>
> On 7/29/07, Adam Fisk <[EMAIL PROTECTED]> wrote:
> > I agree that would be very helpful. A comment in that same method for
> this
> > chunk of code would also be very useful:
> >
> > if (selector.keys().isEmpty()) {
> > synchronized (lock) {
> > if (selector.keys().isEmpty()
> > && newSessions.isEmpty()) {
> > worker = null;
> >
> > try {
> > selector.close();
> > } catch (IOException e) {
> > ExceptionMonitor.getInstance()
> > .exceptionCaught(e);
> > } finally {
> > selector = null;
> > }
> >
> > break;
> > }
> >
> > This relates to the question of visibility and possible use of volatile
> you
> > mentioned earlier. Why are we stopping the selector here, only to
> seemingly
> > start it again when new sessions come in? A comment would be great! If
> > anyone's worried about their English, just an explanation on the list
> for
> > the rationale would be fantastic, and I'd be happy to submit a patch
> with
> > more fully commented code.
>
> The code block above is for stopping the SocketIoProcessor thread
> automatically when there's no sessions to manage. By doing so, we can
> maintain the number of I/O processor therads in an optimal condition,
> and avoid the situation that JVM doesn't exit because of idle I/O
> processor threads.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
--
..Cheers
Mark
