It's been a couple of years since I used threads on Linux, so this may be
out of date, but WTH.
If you want to send a signal, you usually want to send it to a process,
not a particular thread. With the LWP model, there is a single PID,
shared by all the threads, making it easy to send the signal. Under
Linux, you have n PIDs for n threads. Which PID do you signal?
With the LWP model, you can fork() a process, and the new process can
contain duplicates of all the parent's threads. That would seem to be a
challenge with the clone model. In all honesty, I've never had the
slighest desire to actually do a multi-threaded fork(). Since it isn't a
part of the POSIX thread model, this wouldn't seem to be an overwhelming
advantage.
With the m-to-n thread model used by Solaris, you write an application
using however many threads makes sense for that application. At run
time, you can specify how many LWPs you want to use, and the thread
library handles the multiplexing of the application's user-level threads
to the OS's LWPs. This makes it easier to write a multithreaded
application that doesn't overload a two-processor system, but which can
scale up to a 64-processor system.
It is probably possible to implement this m-to-n model on top of clones,
but it seems that migrating a user-level thread from one 'process' to
another could cause some ugliness. One trivial example: getpid() would
return different results at different times during the thread's lifetime.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/