Messages in this thread | | | Date | Thu, 15 Jul 1999 10:16:28 -0400 | From | Nils Nieuwejaar - Sun High Performance Computing <> | Subject | Re: kernel thread support - LWP's |
| |
On Wed, Jul 14, 1999 at 07:10:08PM -0600, Larry McVoy wrote: > Given that that isn't an issue, > can you think of a single technical reason why LWP's would be better?
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/
| |