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

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #49 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #48)
> (In reply to Carlos O'Donell from comment #47)
> > Note that C++ is considering coroutines, and if implemented in C they would
> > represent a case where we could conceptually have multiple execution
> > contexts within the same OS thread. Exposing the OS tid would further
> > complicate programming using these execution contexts since the tid's would
> > be the same. If we stay with pthread_t, we can at least under the hood have
> > a pthread_t per execution context that might be used to allow some threading
> > operations to be shared between the various execution abstractions.
> 
> I'm afraid this argument isn't valid because we use %fs-relative (or
> %gs-relative) addressing, instead of loading the TCB from the %fs:0 and
> addressing relative to that.  As a result, a co-routine switch would have to
> copy the *entire* TCB as part of the context switch, which would not offer
> the performance characteristics people expect from coroutines.

This depends on the semantics of TLS access from coroutines. What is relevant
today is that the decisions we make here may constrain the implementation of
the features defined in the standard, or even the standard itself.

> We are committed to the kernel thread identity, so we might as well expose
> it to applications explicitly.

We should solve problems in ways that leave maximum degrees of flexibility for
future implementations.

Just because it is easier to expose gettid() than to fix the routines that now
expect tid, doesn't mean it's a good idea in the long term.

> There is also a possibility that coroutines will be implemented as
> Python-style generators, where only select functions using a new syntactic
> element can perform context switches, and there aren't any stack switches
> involved at all or anything the lower-level run-time environment would
> notice.

Right, generators would not need anything from the runtime, but they are only
one possibility, and it may be that all such options are pursued by the
standard.

Again, I think we should solve this problem while still retaining the maximum
amount of flexibility for the future.

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