In message <[EMAIL PROTECTED]>,
"Richard Seaman, Jr." <[EMAIL PROTECTED]> wrote:
>> I would really be very grateful however if _someone_ would explain to me
>> the actual low level-mechanics of how this works, i.e. how one thread in
>> a ``multi-userland-thread'' process can manage to get control and/or a
>> CPU time slice when and if a different thread within the same process
>> gets blocked awaiting some I/O completion.
>
>It would be easier for you to read the code (see libc_r/uthread).
>Its very messy. Basically, all i/o syscalls that can block are
>converted to non-blocking. If the syscall would block, the userland
>thread scheduler handles the "blocking", by scheduling another thread,
>and then periodically polling the i/o device to see if its ready.
OK. That is a clear and adequate explanation. Thank you.
I'm not at all sure that I like the idea of something intercepting my
syscalls and rewriting them for me, but I understand why it is being done,
and (now) I understand how the current ``userland threads'' stuff works.
>This is why the userland thread scheduler is not
>very swift, and why user thread context switches are a lot slower
>than kernel thread context switches.
Yes.
It sounds to me like each and every time there is a thread context switch,
some code in the library may have to execute a (perhaps enormous) call to
select() or else to poll(). Yes? (Please don't tell me this is all
implemented with asynchronous I/O completion signals. Yecch. That would
be awfully slow I think.)
>Also note that you can try kernel threads using ports/devel/linuxthreads.
I'm in no big hurry. I'll wait for the freebsdthreads.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
