Messages in this thread |  | | Date | Tue, 6 Aug 1996 09:32:02 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: proc fs and shared pids |
| |
On Sun, 4 Aug 1996, lilo wrote: > > > > Great. Could thread ID 0 mean "all threads at once" and the individual > > threads are numbered starting from 1? That would let me kill -9 the > > whole group at once or just one thread at a time. > > This does sound like a great way to please both those of us who are nervous > about not having unique pids, and those who insist on having them. > > If you ignore the existence of the 16-bit thread ID by zeroing it, you get a > kill which affects all of the threads. > > In fact, this sounds so good that there's got to be something technically > wrong with it.... :) :)
There isn't. We discussed this some time ago (I don't remember with whom), and it was felt to be generally a "good thing". It has the advantage of allowing normal UNIX utilities to automatically work both on the whole "process" (in the traditional thread meaning) while still allowing the same utilities to handle individual threads if they wanted to.
Traditional threads suck. The whole idea with the Linux "clone()" was to look at the thread idea from a new perspective, and have something that makes the difference between threads and processes fade away. We want to have threaded programs, but we ALSO want to not think of the threads as anything special: they are just another form of processes. As such I don't want special thread system calls, instead I want _generic_ system calls that work both in a thread and a process context. That's why I proposed the high-bits thread-ID approach.
The only problem as far as I'm concerned is that I don't actually use the thread facilities, and as such I'm unlikely to start coding. I've been hoping that people that are interested in threads start using clone() for them (which finally has happened, thank God), and that as it becomes clear that we need more support (like the thread ID thing) people start sending me patches. Hint hint..
Again, I'd like people not to look too closely at pthreads or other "traditional" threads packages. If people _do_ start playing around with the kernel for better thread support, please don't try to force any pthread specific system calls or anything like that. Think in more generic terms, and do any new system calls (if needed) in such a way that you can implement pthreads on top of them, but don't limit yourself to any specific interface. Try to make the system calls make sense even _outside_ a threaded environment.
Linus
|  |