Re: Design hole in nptl (and more general in POSIX threads)

Dragiša Durić wrote:
>   I think there is nothing that can mess with single array of indices,
> indexed by register local to thread (TLS space). Of course, if TLS is
> not implemented that way, behaviour is probably random. Same thing with
> pthread_self() - it's probably index zero in TLS, no much reason to be
> anything else, but there remains question of portability.

The "single array of indices" is not async-signal-safe if those
indices are changed by things like loading/unloading of dynamic
objects which some threads might be doing.

For high level language environments, which are the reason for wanting
to use these GC techniques in the first place, dynamic
loading/unloading is another commonplace feature so it can't be ignored.

Also, TLS is not necessarily implemented that way; it's platform
dependent.

>   Thread which we cannot identify at any moment is pretty pointless :).

In practice there's always a way to get a key in a signal handler
which uniquely identifies the signalled thread, but unfortunately it
varies (a lot) between implementations.

For the GC thread-stopping technique, the requirement can be avoided:
simply signal the threads _serially_, although it is messy.

It is never really portable anyway.  You can't safely call
pthread_kill from a signal handler either, so a thread can't halt
itself inside a signal handler.  Also, the only thread-related
async-signal-safe operation, sem_drop, is an optional part of pthreads :)

-- Jamie