Casey Marshall wrote: > 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? Hi Casey, You would continue to need some VM callbacks. Putting the FD in non-blocking mode is not sufficient though I could maybe imagine only rerouting select/poll in such occasions. You will also need the Enter/LeaveSyscall callback to ensure the thread safety of errors. To sum up, you can always invent a bunch of interfaces which can look more compact but they will give you a more obscure code. #if defined(GREEN_THREADS) #ifdef THIS_VARIANT_DOES_NOT_LIKE_THIS_SYSCALL #else #endif #ifdef... #endif #else /* ! GREEN_THREADS */ /* Do some other macro checking */ #endif Put in the perspective of what we already has around the code it will be a mess... > > 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. > Performance drain would a be one more indirection by syscall. I am not sure if it really matters as anyway syscalls are expected to be long compared to a usual function call. I can run some performance test on my computer though. The testcase would be: syscall.c: write some function to alias a syscall. I compile syscall.c with PIC to ensure the worst case. Then: main.c: Call this syscall an huge amount of time. Then compare to calling the real syscall. Regards, Guilhem.
