Hi Casey, there were a series of e-mails on green threads a while ago: http://developer.classpath.org/pipermail/classpath/2006-March/000712.html For the Jikes RVM we assume that most system and library calls are fine, but we special case a few in the syswrap.C file: http://svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/rvm/src/tools/bootImageRunner/syswrap.C?view=markup We actually special case very few as we replace the standard socket library with our own non-blocking variant (which is also slightly problematic). The special cases we have are: select and poll, to support IO pthread_mutex_lock and pthread_cond_wait, to avoid these waiting on a lock already held by the current pthread (and instead calling a Java thread yield) Currently we're thinking of dropping green threads in favor of pthreads as it would remove our IO problems, but this is a fairly fundamental change to the runtime. It strikes me that mileages will also vary whether you have a green threads 1 or 2 model (see my previous post). We have a green thread 2 model, which can't schedule another Java thread unless the current Java thread hangs itself up. I will repost the patch I wrote the VM integration guide describing this too. Regards, Ian Rogers Casey Marshall wrote: > This is a general question for those using Classpath with VMs that > support UNIXy C implementations of native methods, but who use userland > ("green") threads as opposed to native threads. > > My understanding is that the core issue is that you can't become blocked > in a system call, because that will block all threads from running. So > is this restriction *exclusively* for system calls that might block? > accept() and read() clearly may block, so we should provide wrappers > around them that can be replaced with a userland thread-friendly > version, but bind(), getsockopt(), etc. don't seem like they would (they > won't, for example, ever return EAGAIN or EINTR, according to the man > pages). So do "fast" system calls like this need to be wrapped for user > threads, or will it suffice to just call them directly? > > I also realize that the assumption "foo() will not block, because the > docs say so" may not be valid everywhere, since UNIX operating systems > are a minefield of subtle incompatibilities. Some of these functions > *should* just be copying kernel structures into the arguments, but do > any syscalls block, when we should assume that they won't? > > Thanks. >
