Thread and process dentifiers (CPU affinity, kill)

[Olivier Croquette <ocroquette@free.fr>]

It seems that the thread ids in Linux are unique within the complete 
operating system, and not only within their corresponding processes. 
This is explicitely allowed by the POSIX standard (it also states that 
applications shall no rely on it).

Apparently some system calls which normally require a process id also 
work with thread ids.

- a system call requiring a PID can have  the same effect if a thread id 
of the same process was given.
Example: kill(tid,SIGTERM) will kill the entire process the thread
belongs to. I think that this is not POSIX compliant. It shall trigger
ESRCH!

Sometimes, the system call has another effect, potentialy providing
additional functionality.
Example: sched_setaffinity(). The man page and the prototype (which 
requires a pid_t) both show that a process id is required. Nothing 
indicates that it works with threads, and AFAIK there is no documented 
way to set affinity for a specific thread.
But if you give a TID to sched_setaffinity, it will put the *thread* on 
the given cpu set.
If you give a PID to sched_setaffinity, it will put the *main thread* on
the given cpu set. The other threads won't be impacted.
Even if sched_setaffinity() is no standard, I find it confusing to give
it a pid_t and that it affects only threads!


Some open questions:

- is it a guaranted behaviour within Linux that thread ids and process 
ids do not overlap? is it documented anywhere?

- is there a real confusion at API level within Linux between threads
and processes or are kill() and sched_setaffinity() isolated examples? 
or bugs?

- is Linux kill() POSIX compliant in this regard?

- do we want to limit the sched_setaffinity() functionality to
correspond to its documentation, or do we want to update the
documentation so that its covers all the functionality?


Regards


Olivier