>>>>> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
> Michael Thome <[EMAIL PROTECTED]> writes:
>> I think the best answer is to do the second tier threading in userspace
>> (best would be in glibc).
> While on the surface this looks like the simple solution, in practice it
> is very difficult to do.
Heh - I said "best," not "easiest"... :-)
Still, the linux community has managed to do some pretty difficult
things better than commericial vendors.
> It requires that any operation that might block
> the underlying kernel thread (such as a disk or socket I/O) be actually
> made non-blocking and the appropriate call to the thread scheduler made
> at the point where the block would occur. This adds a great deal of
> complexity, as evidenced by the implementation of green threads itself.
> Also, if you really want this to work, you need to inform the user-level
> thread scheduler whenever a kernel thread might block - such as during a
> page fault. While something like scheduler activations addresses this, it's
> not easy to build.
Yes - one would expect a general purpose hybrid/two-tier threading
library to be at least at complex as the green threads implementation:
presumably somewhat hairier. It would certainly be useful to have
some kernel support for such a library (like the page faulting issue
you mention above) - I would imagine that it would be easier to
convince the linux kernel gurus to help out with this than to talk
them into support of any finer-grained kernel-managed threading.
cheers,
-Michael Thome
[EMAIL PROTECTED]
--
Michael Thome ([EMAIL PROTECTED])
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
