On Sun Feb 08 2015 at 12:21:36 AM Victor Stinner <victor.stin...@gmail.com> wrote:
> > Le 8 févr. 2015 05:39, "Gregory P. Smith" <g...@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 >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
