[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid() does not

[Mike Frysinger]

Mike Frysinger <vapier at 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 <greg at 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 <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________