Mike Frysinger <vap...@users.sourceforge.net> added the comment:
> fundamentally: this shouldn't work anyways. > > You are calling wait() from a signal handler. > That is a blocking operation. > You cannot do that from a signal handler. what definition/spec are you referring to here ? is this a Python limitation ? i don't see any mention in the Python documentation on the subject: https://docs.python.org/3/library/signal.html maybe you meant this as an OS limitation ? it's certainly not a POSIX limitation as it's quite clear on the subject: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html > The following table defines a set of functions that shall be > async-signal-safe. Therefore, applications can call them, without > restriction, from signal-catching functions. > wait() > waitpid() in general, the idea that a signal handler "cannot block" is weird. i guess you're saying that anything that involves the OS is forbidden ? there's no guarantee something as simple as a file open() or close() won't block, or really any syscall at all. i bisected a similar testcase from the OP down ... python 3.4.0 works, but 3.4.1 fails. looks like it's due to this change: https://github.com/python/cpython/commit/d65ba51e245ffdd155bc1e7b8884fc943048111f Author: Gregory P. Smith <g...@krypto.org> Date: Wed Apr 23 00:27:17 2014 -0700 subprocess's Popen.wait() is now thread safe so that multiple threads may be calling wait() or poll() on a Popen instance at the same time without losing the Popen.returncode value. Fixes issue #21291. ---------- nosy: +vapier _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25960> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
