sem_wait和信号处理程序

Question

Why sem_wait cannot be used inside a signal handler (particularly SIGSEGV signal which is per thread)? Can someone give me an example scenario where it will crash the application? I guess sem_wait is both reentrant and thread safe , so what is the problem here? Why is it not async safe ?

Answer 1

Async safe is a much stricter requirement than thread safe. You can write thread safe code using primitives to protect global data with critical sections. Signal handlers can't rely on this. For example, you could be inside a critical section within sem_wait, and simultaneously do something that causes a segfault. This would break the thread-safe protections of sem_wait.

Answer 2

What if the application receives a signal while the value of the semaphore is zero, and the thread that receives the signal happens to be the one which is supposed to increment the semaphore value (sem_post)? If you then call sem_wait in the signal handler, the process will deadlock, no?

Another argument could of course be that if sem_wait is not on the list of async-signal-safe functions, the implementation is free to invoke nasal demons.

Answer 3

sem_wait cannot be used in a signal handler for this reason:

Thread A is calls sem_wait on sem1. When thread A is done, it posts to sem1. However, before it can finish the signal is received and then handler is entered, calling sem_wait on sem1. Since A is the one that would post to sem1, the handler will never return and you will have deadlock. This is why it is a good rule to never wait on anything in a signal handler. The problem, ASFAIK, has more to do with deadlock than crashing.

Also, this violates the ideal purpose of a signal handler, which is to handle an external interrupt and then get back to what you were doing quickly.

Lastly, isn't it a better goal to rid yourself of the SIGSEGV instead of handling it?