(original) (raw)

On Sun Feb 08 2015 at 12:21:36 AM Victor Stinner <victor.stinner@gmail.com> wrote:

Le 8 févr. 2015 05:39, "Gregory P. Smith" <greg@krypto.org> a écrit :
\> From there, in your signal handler you must try to acquire the newly exposed keymutex and (...)

Stop! Acquiring a lock in a signal handler is just a crazy idea. It's very far from an async signal-safe function.

I'd normally agree... In this case, sem\_trywait() is non-blocking. It is unfortunately not on the official POSIX list of async-signal-safe functions (of the SEMs, only sem\_post() is) but many implementations actually are safe, documented or not.

https://github.com/lattera/glibc/blob/master/nptl/sysdeps/unix/sysv/linux/x86\_64/sem\_trywait.S - appears safe.

So long as the underlying semaphore is implemented using an atomic instruction on the target platform I wouldn't expect any implementation of sem\_trywait to be async signal unsafe. (nor would I depend on that without checking)

-gps

> So until those are fixed (hooray for Antoine's PEP!), ...

I wrote the PEP with Charles François Natali, but Charles wrote the whole implementation. Antoine also helped us and approved the PEP. It's the french connection! Just to say that Charles did most of the work.

Victor