Problems persist in KQueueSelectorProvider (Mac) in 7u6 ea (original) (raw)

David Schlosnagle schlosna at gmail.com
Mon Aug 13 14:24:59 PDT 2012


On Mon, Aug 13, 2012 at 3:13 PM, Jason T. Greene <jason.greene at redhat.com> wrote:

I threw together a quick patch (attached below against 7u-dev), and it appears to resolve the issues on 6 and 7. Although it needs more testing.

The preClose problem disappears as well with this change. My hunch is that the tight spin loop on kqueue makes it impossible for close/dup2 to ever complete.

Hi Jason,

A few minor comments/questions in KQueueArrayWrapper.java:

Should the updateList and Update instance fields all be final? Is there any reason not to avoid the continue in updateRegistrations()? while ((u = updateList.poll()) != null) { SelChImpl ch = u.channel; if (ch.isOpen()) { register0(kq, ch.getFDVal(), u.events & POLLIN, u.events & POLLOUT); } }

Do you foresee any lock contention issues with the synchronization on updateList? Would using a java.util.concurrent.LinkedBlockingQueue rather than the LinkedList with synchronization violate the API semantics of batching the updates? I was thinking something along the lines of the KQueueArrayWrapper.java diff below would work (but I haven't tested at all).

Thanks, Dave

diff --git a/KQueueArrayWrapper.java b/KQueueArrayWrapper.java index 5a7020c..936f086 100644 --- a/KQueueArrayWrapper.java +++ b/KQueueArrayWrapper.java @@ -34,7 +34,9 @@ package sun.nio.ch; import sun.misc.*; import java.io.IOException; import java.io.FileDescriptor;

+import java.util.Iterator; +import java.util.Queue; +import java.util.concurrent.LinkedBlockingQueue;

/*

@@ -100,6 +105,16 @@ class KQueueArrayWrapper { kq = init(); }

@@ -137,12 +152,31 @@ class KQueueArrayWrapper { } }

u.events & POLLOUT);

@@ -157,6 +191,7 @@ class KQueueArrayWrapper { }

 int poll(long timeout) {


More information about the nio-dev mailing list