In message <[EMAIL PROTECTED]> "Brian O'Shea" writes:
: I was under the impression that, because user thread scheduling is done
: in user mode, a thread that goes to sleep calling a blocking read()
: system call will put the entire process to sleep until that read()
: returns (and so all user threads in the process will also be blocked).
: Is this correct?
No. the pthreads wrappers only make you think that you are calling
read, when in fact it multiplexes things behind the scenes for you.
If one thread is reading, then another thread can be running. All
this assumes that drivers implement select/poll correctly and
nonblocking I/O is supported as well. Really a slick setup for when
you need to do lots of threading, a big pain when you don't due to
locking issues that come up when you trie to dice things into too many
threads. But I digress.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
