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.
