[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Дана нед, 21-12-2003 у 01:53, Jim Blandy је написао:
> My __thread structure contains the links of the list of threads to
> send signals to.  Both adding threads to the list and traversing the
> list sending signals require code to hold the same mutex.  So I have
> always referenced my thread structure before using it in the signal
> handler.  And I don't make any first references to TLS in my signal
> handlers.  So it sounds like I'm okay.

  But, you referenced TLS variable in another thread? Signal handler for
every thread happens in it's thread so you have now reference when your
signal handler asks for that ("same") variable.

> While I appreciate your explanation, the paragraph above is not the
> sort of language one would want to put in a spec.  When POSIX gets
> around to recognizing the existence of __thread variables, it will
> need to find a description of what is permissible that reveals less
> about the implementation.  I hope they will not simply declare it
> non-async-safe altogether.

  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.

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

> Perhaps they could say that volatile __thread variables may be safely
> referenced in signal-handling code only if they are first referenced
> in non-signal-handling code.  (Without the 'volatile' qualifier, this
> requirement would create a new class of variables for the compiler
> which it could not optimize out references to.)

  Compiler cannot use what is not provided by pthread, if it does not
make workarounds around above problem for each and every platform.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]