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
