Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?

[Farid Hajji]

Niels,

> > Even if you don't plan to implement N:M, could you point us to an
> > existing implementation or to a description of the underlying theory?
> > Implementing multiplexing threading libraries looks quite scary to me
> > at the moment (you know, the "black art" aspect...) ;-)
> 
> I found the white paper on the Solaris threads implementation
> enlightning. Sorry I don't have an exact reference, but it's been
> mentioned here in the past. Let me know if you have trouble finding
> it, and I'll try some harder to find the URL.
Michael Hohmuth just posted it on this list:
  http://www.usenix.org/events/usenix01/freenix01/wood.html

as well as this one (yes, someone pointed out that IBM was doing
Pthreads on this list earlier):
  http://oss.software.ibm.com/developerworks/opensource/pthreads/

Then we should look at C-Threads more carefully, as it may be an
N:M implementation already (thanks Michael). I'm currently studying
the uthreads Library from Birrel (FreeBSD) and that seems to be
a good candidate too.

Time to do some serious code analyzing and then hacking! ;-).

> It seemed that the most tricky parts were (i) creating more kernel
> threads on demand, to avoid deadlocks, and (ii) to get signal
> handling and per thread signal masks right.
(i): As far as L4 is concerned, we've got a fixed-size pool of threads
and a library to activate them (at least starting with X.1 a.k.a. Version
4 kernels; X.0 being rather cryptic). If L4 evolves to provide thread
objects (as abstractions) as was hinted in "The L4Ka Vision" paper, the
kernel-thread interface would mostly become even easier. Regardless of
this, even X.0 threads could be accessed from a library of some sort.

Creating more kernel threads on demand would just mean assigning
more kernel threads to the multiplexer/scheduler. The hairy problem,
as I'm currently understanding it, is that we must ensure that at
least one kernel thread acts as a garbage collector (or if you prefer
as a watch dog) that would wake up kernel-threads that deadlocked
because the user-threads, that were multiplexed on it themselves
deadlocked in a unforseen manner. Hmmm...

(ii): Aww, signal handling _is_ a difficult part in every thread
implementation. But we're talking about a low-level thread package
here, that will _not_ be based upon a Unix-like system. The kind
of "signals" we are concerned with, are mostly interrupts and
probably some kind of IPC (probably just returing from msg_get()).
We don't need to do signal handling a la POSIX here. It may be
even possible to assign a service thread that would handle signals
(whatever this may be) exclusively, so the signal issue would become
moot. (BTW: how are signals handled in the Hurd itself? ;-)).
Well, let's see.

> Regards,
> /Niels

Thanks,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.