Message362583
> 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@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. |
|
Date |
User |
Action |
Args |
2020-02-24 10:29:37 | vapier | set | recipients:
+ vapier, gregory.p.smith, chris.jerdonek |
2020-02-24 10:29:37 | vapier | set | messageid: <1582540177.0.0.935933025352.issue25960@roundup.psfhosted.org> |
2020-02-24 10:29:36 | vapier | link | issue25960 messages |
2020-02-24 10:29:36 | vapier | create | |
|