Re: swapcontext happening on different threads

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 03/12/2024 00:24, Andrew Pinski wrote:
> Reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65712 .
> 
> I am not 100% sure if this is a valid thing to do.
> But take the code in the referenced GCC bug report. Currently since
> pthread_self is marked as const, if you swap to a different context
> and then have that context be swapped on a different thread, you
> might/will get the old value of pthread_self in some cases.
> 
> Is this well defined or is this a corner case that was not expected. I
> don't see anywhere in the older versions of POSIX that explain what
> would happen if you do that. And glibc's documentation does not talk
> about this case either.
> 
> It would be useful if the documentation talked about this either way.

yeah.

my view is that resuming on a different thread is invalid.
(tls address or other thread specific state cached on the
stack is broken).

there are known users who switch between threads via swapcontext,
i think they are on their own to ensure things work since they
are in undefined land (maybe the compiler could help with
appropriate barriers).

otoh const pthread_self is theoretically wrong even without
swapcontext breaking it: the compiler can cache const func
output into a per-process global variable as far as i can
tell. (iirc there were bugzilla discussions before that
attribute const should not allow exception return or different
return values in different threads. btw this affects
__errno_location too in glibc)