The wait I'm referring to is the one on the semaphore underlying to the condition variable (pthread_sem_take on cond->sem). This ends up as a call to nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I understand that a signal would not interrupt the wait (and thus, the call to pthread_cond_wait).
On Tue, Jan 12, 2021, at 20:34, Gregory Nutt wrote: > > > I'm having an issue when waiting on a pthread condition variable from > > the main thread and then a signal handler runs, which should cancel > > the wait since I have cancellation points enabled, however this did > > not happen. While debugging I see the main thread blocked when > > standing inside the signal handler. Here's the call graph at that point: > > There are two semaphores associated with a condition variable wait: a) > One for the conditional variable and b) one for a mutex that protects > the condition variable. When you wait for a condition, the mutex (b) is > unlocked and the logic waits on (a). After (a) wakes up, then mutex (b) > is re-relocked. So there can be two waits. > > What is not clear from the call graph is if the sem_wait() is the first > for the condition variable or the second for the mutex. > nxsem_wait_interruptible() is fine for for the first, but not for the > second if ECANCELED was returned. > > >
