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 #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.


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