Hacker News new | ask | show | jobs
by gpderetta 3587 days ago
Note that the lock is a red herring. A single threaded malloc wouldn't be async signal safe either unless explicitly designed to be so which is hard. In fact anything that touches mutable state, including thread local state is a problem.
1 comments

Yeah, good point. The weird part is that it almost introduces a new thread, in that it introduces a new flow of control (and, if you ask for it, a new stack), but it doesn't count as a new thread in all the usual ways, like thread-local variables or PIDs. So any code called from a signal handler must be "thread-safe", but that thread-safety cannot rely on assigning an identifier to the thread, because you're using the same identifier as the parent thread.
> Yeah, good point. The weird part is that it almost introduces a new thread, in that it introduces a new flow of control (and, if you ask for it, a new stack), but it doesn't count as a new thread in all the usual ways, like thread-local variables or PIDs.

Worse: most signal handlers that do anything other than setting globals destroy errno in one way or another and when you go back the code that was interrupted has a good chance of malfunctioning.