FULL PRODUCT VERSION :
Observed on 1.5.0_02 and verified in java 1.5 jdk windows specific source code

ADDITIONAL OS VERSION INFORMATION :
Any version of Windows

A DESCRIPTION OF THE PROBLEM :
There is a racing condition in sun.nio.ch.WindowsSelectorImpl. The racing condition may make a call to java.nio.channels.Selector.select block forever even if it was supposed to return immediately.

Consider the case where a thread A calls doSelect. doSelect will call adjustThreadsCount. Suppose adjustThreadsCount creates a new SelectThread B. Suppose A is then suspended for some time and that instead B starts executing. From SelectThread.run B will then make a call to startLock.waitForStart and then to subSelector.poll. Suppose this call returns immediately, then B will continue with calling finishLock.threadsFinished and then startLock.waitForStart which will then block. Suppose that A is not resumed until this point. Then A will call finishLock.reset() and this will prevent A from ever returning from doSelect.

The bug I repported is due to a programming error in sun.nio.ch.WindowsSelectorImpl, not due to limitations on the Windows platform. I found the bug as follows: From time to time my program blocked completely. I then reviewed the jdk source code where I found the bug I reported here. This bug explains the behaviour of my program. Also, during debugging I wrote out thread dumps and these dumps confirm that the reported bug is indeed a bug. Finally, the problem happens exactly when the number of sockets in the selector goes from 1023 to 1024. These numbers are magic in sun.nio.ch.WindowsSelectorImpl, not in my program. So I am almost as sure as you can get that this is indeed a bug in the jdk.

REPRODUCIBILITY :
This bug can be reproduced occasionally.

CUSTOMER SUBMITTED WORKAROUND :
Never register use more than 1023 keys on a selector.
###@###.### 2005-04-26 11:59:55 GMT