This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/6399] gettid() should have a wrapper


https://sourceware.org/bugzilla/show_bug.cgi?id=6399

--- Comment #42 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
(In reply to Carlos O'Donell from comment #41)
> (In reply to Florian Weimer from comment #40)
> > We are committed to a 1:1 threading model because userspace code manipulates
> > task attributes such as CPU affinity or capabilities, and all kinds of
> > things will break if we start switching userspace threads to different
> > (still userspace, obviously) kernel tasks.  (Restoring all those attributes
> > on context switch is not possible for performance reasons.)
> > 
> > This means that Ulrich's objection to adding gettid is no longer valid.
> 
> I've talked about this a bit before, and I'll mention it again for good
> measure.
> 
> The biggest problem is that the design in Linux for this stinks. The reuse
> of pid_t as a type for tid's is confusing IMO and was a design flaw.
>
> Therefore if we are to carry this out we need to thoroughly think about what
> it means to expose a tid, should we use a distinct type, what is that type
> going to look like? Should users be able to convert from pthread_t to to
> tid_t and vice versa? Do we want new interfaces that take tid_t types for
> all those things you'd do with native threads or should the interfaces that
> take pid_t document their support for being called with tid_t values?

I'm not so convinced about this. 

1. At the kernel level, we have APIs operate on PIDs (e.g., kill()) and APIs
that operate on threads (e.g., rt_tgsigqueueinfo()).

2. In kernel thread groups, the so-called thread group leader is the one whose
PID is the same its thread ID. That is, these two values are exactly the same.
In APIs that operate of threads, specifying the "PID" means operate on the
thread-group leader.

3. There is plenty of precedent for the preceding model. We have the
session-process group-process hierarchy. Session IDs, process group IDs, and
process IDs are all represented using the same type: pid_t. And we have the
corresponding notion that a session leader has SID == PID and that a process
group leader has PGID == PID.

At the kernel level, there is really only one kind of kernel scheduling entity
(LSE) -- commonly called a "task" in Linux parlance. And that one kind of KSE
is identified by one kind of data type. Creating an artificial distinction at
the glibc level seems illogical and confusing. Furthermore, the clone(2) system
call, which creates kernel "threads", returns a thread ID. But really, this is
the same for processes: clone() is equally the creator of "processes". And of
course, glibc itself already assumes that TIDs and PIDs are the same thing,
since nowadays glibc's fork() is a wrapper around clone(), and that wrapper
assumes that clone() returns a PID.

In short, I'd say that everything should be a pid_t.

> Either way, someone needs to start with a coherent design for what this is
> going to look like.

The only sane thing to do, AFAICS, is to use pid_t. And on that assumption,
much of the design work is greatly simplified.

And yes, for Pthreads applications that want to exploit nonportable Linux
pieces, it would be nice to have functions that translate pthread_t <==>
kernel-TID.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]