In other words, although I was creating a nonblocking socket and issuing
read calls against it in JNI-based C code, those system calls (from C)
were in fact being caught by the Java runtime library which was turning
them back into "blocking" access to the socket. This is because the green
threads library is very aggressive about preventing native code from stalling
the whole application by issuing a blocking system call - it in fact turns
all blocking system calls into nonblocking calls, and issues (green thread)
context switches when a block would occur.The solution? Go behind JNI's back, and get the "real" system call handles
by using dlopen/dlsym on /lib/libc.so.6 (or wherever your standard C library
happens to be installed), and call them directly.
Isn't that a bit dangerous?
It sounds like looking for trouble with the green-threads lib by mixing
it with direct access to the system libs. It should be really nasty to
debug, in the very likely case of unexpected behavior...
(apart from that, it's a very cool hack though ;-)
The good news is that it seems to work. Note that when native threads are used,
the JDK does not attempt any funny business, and there are no problems.
Since the thread proliferation problem really affects only native
threads vm, why don't you fall back to thread-based i/o on detecting green
threads (where you can simulate non-blocking i/o by creating the usual
mess of buffers and i/o devoted threads)?
I know that it's a mess, but I would expect to get more predictable
behavior in this way.
-- dimitris mailto:[EMAIL PROTECTED]
