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

[Niels Möller]

Farid Hajji <address@hidden> writes:

> > 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.
> 
> 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...

I don't quite understand you here. It's not the kernel's or the
library's job to fix deadlock-bugs in user code (ok, it would be nice
if it did that, but I don't think it's common). The problem is as
follows: Say there are N kernel threads, and M>N user threads. Of the
N kernel threads, most are hanging waiting for i/o, while some is
blocking on a mutex. The mutex is currently locked by the N+1:th user
thread, which isn't currently assigned a kernel thread.

I'm not sure I get the scenario quite right, but the problem is that
in order to get progress, the N+1:th has to be assigned to a kernel
thread so that it can run until it releases the mutex, and in some
situations, the way to do that is to start one more kernel thread.

> (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.

Ok. A was under the impression that the aim was for pthreads
conformance. I'm not sure exactly how signal aware you have to be to
say that you are pthread conformant, but at least in a unix-like
environment, you'd want it to do the right thing.

On the other hand, signals are implemented very differently on the
hurd than on unix, which may make the problem easier to solve. And
even a thread package with broken signaling behaviour would be a
useful thing to have.

I don't really know these things well, the above is based on my
reading of the Solaris thread paper some time ago.

/Niels