popen2.Popen3 process destruction

This could possibly be a bug, but I don't understand it fully
so I'm posting here first. Searching the list told me other
people are having this problem too.

I have created a class which inherits popen2.Popen3.

The problem is that popen2.Popen3 does not define a __del__
method to handle proper closing of the pipes or destruction of
the process. So I created one in my class:

def __del__(self):
self.tochild.cl ose()
self.fromchild. close()
if self.childerr:
self.childerr.c lose()
try:
os.kill(self.pi d,15)#SIGTERM - ASK NICELY
except OSError:
os.kill(self.pi d,9)#SIGKILL - BE RELENTLESS

However, since the popen2 module stores a reference to the
object in popen2._active this __del__ method is never called
to clean things up. _cleanup() called in Popen3.__init__ ()
fails to clean up the process in subsequent instantiations.
This eventually leads to an "OSError: [Errno 24] Too many open
files"

"_clean()" fails because the program being called is
interactive using stdin/stdout. Much in the way "cat" is. In
fact the unit test provided with the popen2 module _test()
uses "cat" and hangs for the very same reason. It hangs on
"for inst in _active[:]:inst.wait()" This is why I created my
own class, to handle this special interactive nature.

The only workaround I currently see is ripping all but the
"_active.append (self)" from the popen2.Popen3._ _init__() code
and putting it in my __init__. Currently I just call it
directly as prescribed by the python reference manual.

Perhaps I'm missing the epiphany of why _active and _cleanup()
are needed and not a __del__() method.

Thanks,
-Brian

System info:
IRIX64 6.5
Python 2.2.3

[Donn Cave]

In article <ma************ *************** *********@pytho n.org>,
<br****@temple. edu> wrote:

I have created a class which inherits popen2.Popen3.

The problem is that popen2.Popen3 does not define a __del__
method to handle proper closing of the pipes or destruction of
the process. So I created one in my class: .... However, since the popen2 module stores a reference to the
object in popen2._active this __del__ method is never called
to clean things up. _cleanup() called in Popen3.__init__ ()
fails to clean up the process in subsequent instantiations.
This eventually leads to an "OSError: [Errno 24] Too many open
files"
The instance needs to keep itself around, to work with popen2
and popen3 functions and generally support direct use of the
pipe fileobjects and file descriptors.
"_clean()" fails because the program being called is
interactive using stdin/stdout. Much in the way "cat" is. In
fact the unit test provided with the popen2 module _test()
uses "cat" and hangs for the very same reason. It hangs on
"for inst in _active[:]:inst.wait()" This is why I created my
own class, to handle this special interactive nature.

That is not normal, that I know of - test_open2.py's use
of cat should not cause a hang. Unless we're looking at
very different versions of test_popen2.py. I wonder if
there could be a problem somewhere in the IRIX64
implementation of Python, or in the OS itself.

Donn Cave, do**@u.washingt on.edu