On Sun, Dec 16, 2001 at 05:41:14PM +0100, Farid Hajji wrote: > [...snip...] > > I don't think this has much to do with the actual pthread implementation > > used, except that, because glibc in the Hurd uses threading itself, pthreads > > for the Hurd should be integrated closely with glibc, and that we need one > > or two features in the threading package that goes beyond POSIX threads > > (condition implies, I think, from hearsay). For you it means, if we are > > going to use NGPT, we want it to be included in glibc and we want it to > > support the extra feature(s) we need (I think it is really only one, but I > > never checked). > >From a portability point of view, _any_ pthreads implementation in glibc > would need to provide a clear interface to the underlying native kernel > threads. We will have to wait and see what the upcoming L4 Version 4 API > (X.2) will provide in terms of threads API. Once we know, we'll be able > to evaluate misc. threading libraries, including NGPT. Right now, its > only vaporware, as far as l4-hurd is concerned ;-)
As far as that goes, the usual stuff is creating/suspending/destroying threads, setting their priority and, for user space switching, setting the CPU state, isn't it?. Is there much room for innovative thread interfaces at the (micro)kernel level? Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
