Gerald Gutierrez <[EMAIL PROTECTED]> writes:
> I'm starting to pull out my hair from the fact that the current JDK is
> based on user threads. I can't call anything that can potentially block,
> because everything will block.
"Green threads" converts all your blocking I/O into non-blocking ones
by providing wrappers around read/open etc. You should not be able to
write a Java program that starves/blocks all other threads[1]; if you
can, then it there is a bug in the green threads implemenation.
In general, yes, green threads are a pain in the behind.
> An alternative is Kaffe, but it's too incomplete to be usable right now.
> Is anyone working on producing a version of the JDK that uses native
> threads ?
I played with the JDK sources, and noticed that it is possible to port
JDK to run on Xavier Leroy's LinuxThreads. A casual hack is one
thing, but a product version is another.
Didn't Open Group announce a native threads port of 1.1.6 on this
list? I've lost the URL.
> I remember reading about some "problems" with this. What are the problems?
The basic problem is that POSIX threads (the API implemented by
LinuxThreads) doesn't have suspend and resume primitives. These are
required because:
- Of the need to support the java.lang.Thread.suspend() and resume()
methods (these 2 have been deprecated in 1.2).
- Sun's implementation starting a new thread suspended.
- You need to suspend other threads during garbage collection.
Note to friends of LinuxThreads:
LinuxThreads FAQ indicates that one workaround is to post SIGSTOP and
SIGCONT signals and these are akin to suspend/resume. However, I
noticed that if a process flags has PF_PTRACED, the SIGSTOP isn't
really delivered, meaning I can't run the VM under gdb -- which makes
this option useless. I'll have to find an alternative solution for
suspend/resume.
LinuxThreads uses SIGUSR1 and SIGUSR2, so it is not so embeddable.
Don't get me wrong -- I like LinuxThreads, I was impressed by the
cleanliness of its implementation, and it just works, but threads the
kernel really understood would be nice.
-Anand
[1] Two caveats:
- compute bound threads can starve other threads. But there is a
un-supported -ts flag that makes the green threads VM time slice.
- native methods can short-circuit the wrappers and block. Native
methods in the JDK don't do this.
Also System.in.read() is known to block the entire process on
Solaris green threads atleast (fixed in 1.2).
