-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Mar 29, 2000 at 11:13:12AM -0800, Linus Torvalds wrote:
> The feature, right now, is that external programs _can_ see individual
> threads, and can send signals to them individually (and manipulate them
> individually in other ways too - ptrace() etc). That is important, and in
> a very real way you should think of the "kernel pid" as a global thread
> ID. Something that uniquely identifies a thread (not just within a
> process, but in general). And such a global thread ID is important for
> exactly the reasons mentioned.
>
> The downside is that it looks quite ugly in "ps" listings etc, and there
> would certainly be advantages to hiding the "subthreads" in some sense, so
> that while the global thread ID _exists_, you don't normally see it. One
> way of doing that would be to only show unique VM's in /proc/<pid>/xxx,
> and the "subthreads" would show up as /proc/<masterpid>/<subpid>/xxx or
> something.
Yeah, I think it's useful to have ID's for each VM as well as for each
task. There are some things that make sense on a task level and other
things that make sense on a VM level.
> The way these things should work, in my opinion, is that when you
> externally send a signal to the "main thread" (the one whose 'pid' the
> thread collection sees), that signal gets distributed in the POSIX signal
> sense to all the subthreads. But you should still be able to send a signal
> to a specific subthread by using _its_ "native pid" aka "thread id".
If there is the ability to identify the VM with an ID, then it would
make sense to follow POSIX semantics for signal delivery if you did
this. If you send a signal to the task ID, then it would make sense to
follow pthread_kill() semantics as closely as possible (pthread_kill()
doesn't work with threads outside your VM, so this would be more
sophisticated --and perhaps slower?).
> Note that when I started doing clone(), I basically said: "this is how I
> think threads should be done". I added a few example flags to show the
> concept, without really having a firm plan on what the final situation
> would be. Some of those flags got expanded upon (CLONE_PARENT is only the
> latest addition), while some ended up not being very useful at all
> (CLONE_PID is basically useless - the only use for it is to start up the
> original idle threads under SMP, and that code is so specialized anyway
> that it could basically do the CLONE_PID logic by hand).
I think perhaps there needs to be a different ID from the "kernel pid"
which is shared only if CLONE_VM is used. Does this make sense?
> Shared signals are potentially useful outside pure threading models too,
> and I'm looking for something more generic. I suspect that what I'm
> looking for is more like a message list, along with some thin
> compatibility code to make it easy for pthreads emulation that looks like
> signals..
Yes, I like this concept a lot. It might even be possible to push a
lot of that into userspace with some minimal hooks in the kernel.
- --Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE44lxNfrrCpthD+UYRAuCiAKDldDux2rZZ6SK+Osz174t8bURcsACgrMet
LWX5YvYQ7IhDXjBCplsQHn4=
=rbkx
-----END PGP SIGNATURE-----
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:25 EST