On Feb 2, 2006, at 10:27 AM, Guilhem Lavaux wrote: > Casey Marshall wrote: >> On Jan 31, 2006, at 6:10 PM, David P Grove wrote: >>> Jikes RVM also does m-to-n threading, so it's there's more than 1 VM >>> that's whacky in this regard. The things we need to do are most >>> likely >>> different than what Kaffe needs to do, but having a chance to >>> inject a VM >>> callback before the thread dives off into a blocking system call is >>> something we would like to be able to do. We have some linux >>> specific >>> hacks (evil with dlopen to intercept poll, select, etc), but >>> it's fragile >>> and doesn't work on other platforms like AIX and OS X that Jikes >>> RVM runs >>> on. >>> >> Would my suggestion for Enter/Exit callbacks help this? > > Though enter/exit callbacks may help for a few syscalls but it > won't for some (like blocking read/write). For these new calls you > need handle blocking queues in the VM thread scheduler. That needs > to put the fd into non-blocking mode and when you do a read you > first check if there is any data (in non-blocking mode) and if > there is not data then the thread system queues the current thread > and tells the scheduler to jump somewhere else until some datas are > available on the specified fd. So we must really stick to rerouting > a few IOs. I am sure that handling m-to-n threading system is as > difficult as what we are doing (maybe more). > Aha, I grok the issue now. Would it make sense to do conditional compilation based on a "green threads" model, so that you can compile all blocking I/O calls to support such a model, if configured thusly? Or would file descriptor callbacks help -- where the FD is put into non-blocking mode before the call, then reset after, with support to catch the `EAGAIN' if it arrives? Also, I'm sure you could write a kernel-threads compatible library that also supported user-mode thread models at the same time (the restrictions on the former seem to be a subset of the latter), but don't know about what performance drain that would incur on kernel threaded systems. Because, "one POSIX library to rule them all," that supported both thread models, would still be an awesome thing.
