lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kernel thread support - LWP's
Date
From
: 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.

Nonsense. When I do

$ cmd | cmd2 | cmd3
and then hit ^C, I certainly do not want to kill one process, I want to
kill all of them. There is this age old concept called process groups
which makes this work. And process groups work just fine for killing a
related group of cloned processes.

: 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?

This is just silly beyond words. The Linux model is _clearly_ the
superset of the LWP model. Under Linux I can kill a specific thread
or all of the threads, using the same interfaces Unix has had since v6
or earlier. Under the LWP model, I can kill all the LWPs. I can't kill
a specific one. And that's really a drag - maybe I want to use SIGUSR1
or SIGHUP to turn on debugging on a per thread basis. Under Linux, that
just works, with no new code to be written, no new commands to be added,
no new model to be understood.

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

Err, umm, I guess I'd want to see a real world example of somebody wanting
to do this to really understand the need. Until then, this sounds sort of
like a made up example to win an argument.

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

On Linux, it doesn't matter. Use the right number of threads from the
beginning, the OS is more than capable of context switching them fast
enough on a 2 processor system.

: It is probably possible to implement this m-to-n model on top of clones,

But why would you want to? The only reason is if your processes are
so bloody slow that you must use threads. Suppose for a moment that
process context switches and thread context switches both cost the
same, hell, let's say they both cost 0. Then what possible reason
would there be to have user level threads?

--lm

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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.074 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site