Thread and process dentifiers (CPU affinity, kill)

From: Olivier Croquette
Date: Thu May 19 2005 - 13:03:45 EST



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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/