Select() does not block

Question

I cannot provide simple code for this yet. Nondeterministically,
my calls to Selector.select() do not block. That is, they return
immediately, and they return 0. There are no calls to
Selector.wakeup() in the program, and I check that
isInterrupted() == false from the thread that invokes select().
The Javadoc states that these are the only two circumstances in
which a return of 0 from select() should be possible.
When this starts happening, it happens consistently ad infinitum,
but it doesn't start happening in every execution.
This happens with JDK 1.4.1-RC but NOT in JDK 1.4.0. I cannot
easily roll back to JDK 1.4.0 because the OP_WRITE select()
behavior has changed, and what I distribute must work with later
versions of the JDK.
I realize that, without a simple test case, it will be hard for anyone
in this forum to diagnose this. I am hoping that, nevertheless,
someone has some good speculation.
I must say, I wish I had coded this in C++. This NIO seems to be
rather shoddy so far.
Thanks in advance,
Juan Leon

Answer 1

What platform are you using? I took a look and quickly found myself looking at a native method call in a platform-specific class. (sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(), specifically.) The provider (SelectorProvider.provider().getClass().getName()) might be helpful in diagnosing this. On my system (JDK 1.4.1_01, Win XP) it is: sun.nio.ch.WindowsSelectorProvider.
With a little help from Jad and some hand editing of the formal arguments to poll0(), I get:
private int poll() throws IOException {
    return poll0(pollWrapper.pollArrayAddress,
        Math.min(totalChannels, 1024), readFds, writeFds, exceptFds, timeout);
private native int poll0(long address, int channels,
    int[] readFds, int[] writeFds, int[] exceptFds, long timeout);selectNow() pretty much just calls doSelect(0L) in a synchronized block, so I think hoping it will reset things is futile.
WindowsSelectImpl.doSelect(long) looks like this:
    protected int doSelect(long l) throws IOException {
        if (channelArray == null)
            throw new ClosedSelectorException();
        timeout = l;
        processDeregisterQueue();
        if (interruptTriggered) {
            resetWakeupSocket();
            return 0;
        adjustThreadsCount();
        finishLock.reset();
        startLock.startThreads();
        try {
            begin();
            try {
                subSelector.poll();
            } catch (IOException ioexception) {
                finishLock.setException(ioexception);
            if (threads.size() > 0)
                finishLock.waitForHelperThreads();
        } finally {
            end();
        resetWakeupSocket();
        finishLock.checkForException();
        processDeregisterQueue();
        return updateSelectedKeys();
    }As you can see, when all is said and done it calls the native method mentioned above to do all the work, which most likely calls your system's poll() (or possibly select()?), which may be where your problem actually lies. Another poster suggested it may choke on certain channels (closed w/ half-open socket) -- is it possible for you to remove them from the set before calling select? (I know you shouldn't have to, but....)
By the way, updateSelectedKeys() iterates over the helper threads calling the subclass's processSelectedKeys() method, which in turn calls processFdSet() three times: once each for the readFds, writeFds, and exceptFds. This is what actually computes the return value, and the problem could be here, but isn't likely to be, since you say it isn't even blocking.
Anyway, I've gone on long enough, and I'm sure you can use Jad (or some other decompiler) as well as I can. I'm certainly no nio expert (in fact, I haven't used Selector), and this is only what I found after a quick glance into the code.
Whoa! While proofreading this, that "if (interruptTriggered)" block suddenly jumped out at me. If interruptTriggered is getting stuck on that could cause your problem. It's private volatile boolean and is false initially, then set in wakeup() and reset in resetWakeupSocket().
Jad (v1.5.8e2) coughed while decompiling resetWakeupSocket(), but I think it's:
    private void resetWakeupSocket() {
        synchronized (interruptLock) {
            if (!interruptTriggered)
                return;
        resetWakeupSocket0(wakeupSourceFd);
        interruptTriggered = false;
    }resetWakeupSocket0() is another native method. You'll get some insight into your problem from studying WindowsSelectorImpl (or whatever the implementation is on your platform), but you're going to find that you need to look at the several native methods being called to really determine what's going on.
Good luck,
David R. Conrad