After the remarks that the high bits of pids being used for other
purposes, yes, maybe it is more sensible the have separate tids and not
overuse the pid. I liked the pid encoding for its versatility, though.
However, the new idea of actually having different pids for threads
while keeping one pid aside to refer to the whole process was a rather
interesting one. The threads could still be hidden behind the pid that
represents all the threads in /proc. Still, some kludgyish solutions
would be called for; getpid() for example would have to return the
"master pid" and not the pid of the individual thread. That makes me at
least a bit wary of the idea, although it seems otherwise nice (for
example, old syscalls could be used; you'd need a gettid() which would
get the _real_ pid though but all workable schemes seem to need that).
Anyway, if separate tids are to be used, I don't think kludging old
calls to manipulate single threads would be a good idea.
> What we may want to do is to add additional system calls that accept an
> additional tid parameter in addition to existing pid parameters and have
> the existing versions just call the new system calls with a tid of 0
> (all threads), or 1 (main thread), as appropriate.
Yes, some additional system calls would be necessary in this scheme for
sending signals to specific threads etc. However, for a multithreaded
pid your scheme is too simple. Killing a pid that contains multiple
threads should do the posix thing (which has been quoted a few times
already, I think) regardless of whether the threads themselves are
other pids of which the killed pid is the master, or tids inside the
process.
-- Mikko Rauhala, reservin sivari - mjr@iki.fi - http://www.iki.fi/mjr/