[lkml]   [1996]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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


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