>Linus spoke some time ago on this on some linux-kernel thread.
>Basically his consensus was that adding a thread_id that was seperate
>from the normal pid was asking for trouble and a stupid idea.
>
>He instead postulated an idea of encoding the thread_id within the
>pid itself, using the high order bits of the pid value or something
>similar. The nice results of this are that nothing breaks, like
>/proc/pid etc.
Except surely this breaks any future move to a longer pid_t. You could
argue that if we have a 64 bit pid_t, then the lower 32 bits should be
more than enough for the PID, with the upper 32 bits for thread_id and
any other information. But then again, that's probably what they thought
about 16 bit PIDs all those years ago...
Tet
-- --==<< ``Reality is for those who can't handle science fiction'' >>==-- --------------------+--------------+---------------------------------------- tethys@ml.com | Micro$oft: | Linux, the choice of a GNU generation. tet@astradyne.co.uk | Just say no! | See http://www.uk.linux.org for details