donn at u.washington.edu
Thu Mar 27 02:04:30 CET 2003
Quoth "Francis Avila" <franga at shentel.net>:
| I'm still curious as to why popen2() is not closing the pipe in this
| context, while popen() is.
It's a feature - the popen2 module deliberately keeps a list of
Popen instances, so that it can wait for completed processes.
Another peculiarity I noticed when I tried this out - on some
platforms, when you run "yes" with popen2(), the process even
survives its python parent, and not only survives but becomes
very active. This is because python turns off SIGPIPE (sets
it to SIG_IGN), and on some platforms the fork inherits this
setting. When the pipe closes, the child then unblocks and
starts writing as fast as it can. You don't see this on Linux,
I suppose SIG_IGN is not inherited there, but it happens on
NetBSD for example.
Almost as bad or worse, depending on your expectations, on
NetBSD this jams popen(), too, because finalization of its
file object includes a wait(2) for the process status. The
process doesn't terminate, as discussed above, and the
readline() never returns because it got stuck on the close.
So it may be a good idea to restore default SIGPIPE handling
routinely before running external processes.
Donn Cave, donn at u.washington.edu
More information about the Python-list