Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

Started by Florian Weimer on Nov 23, 2018

open the first message on its own page

Message details and related content
* Rich Felker:
On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
quoted
* Rich Felker:
quoted
On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
quoted
There has been presumptions about signals being blocked when the thread
exits throughout this email thread. Out of curiosity, what code is
responsible for disabling signals in this situation ? Related to this,
is it valid to access a IE model TLS variable from a signal handler at
_any_ point where the signal handler nests over thread's execution ?
This includes early start and just before invoking the exit system call.
It should be valid to access *any* TLS object like this, but the
standards don't cover it well.
C++ makes it undefined:

  <http://eel.is/c++draft/support.signal#def:evaluation,signal-safe>
C also leaves access to pretty much anything from a signal handler
undefined, but that makes signals basically useless.
Access to atomic variables of thread storage duration is defined,
though.

Thanks,
Florian
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help