Q: userland threads and system calls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux