This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/6399] gettid() should have a wrapper
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 07 Oct 2015 14:05:58 +0000
- Subject: [Bug libc/6399] gettid() should have a wrapper
- Auto-submitted: auto-generated
- References: <bug-6399-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=6399
--- Comment #41 from Carlos O'Donell <carlos at redhat dot com> ---
(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?
Either way, someone needs to start with a coherent design for what this is
going to look like.
--
You are receiving this mail because:
You are on the CC list for the bug.