On Wed, Mar 18, 2020 at 1:31 PM Gregory Nutt <spudan...@gmail.com> wrote:
> > To get the behavior POSIX specifies ("If a signal is delivered to a
> > thread waiting for a mutex, upon return from the signal handler the
> > thread resumes waiting for the mutex as if it was not interrupted.")
> > would require additional handling, such as (I'm guessing) checking the
> > cause of the wake-up and looping if necessary. Admittedly I don't know
> > enough about the subject and the internals to propose a specific
> > solution yet.
>
> I think that you could set a signal mask to block all signals except the
> one that wakes up the timed wait and the one that could cancel the
> task/thread.
>
> There are some complexities and the possibility to break things. If you
> want, you could just create an issue with all of the relevant
> information and let it pend of awhile. I don't think there is any rush
> to change this behavior, is there?
No, there is no rush.
The reason I went down this rabbit hole (and found this issue) was
because I was trying to decide on a synchronization method between a
low-priority background task and a high-priority timer-driven task,
which share some data with each other. My current thinking is to use
the simplest mechanism, which is a semaphore, and explicitly handle
the case where the wait ends due to a signal.
Also, there is no rush because I think it's better to keep the
behavior we currently have, rather than break things by rushing to
"fix" something.
Where should I file it? It looks like the project settled on using
GitHub for issues.
Thanks for all your help,
Nathan
