«

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.close()
self.fromchild.close()
if self.childerr:
self.childerr.close()
try:
os.kill(self.pid,15)#SIGTERM - ASK NICELY
except OSError:
os.kill(self.pid,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

In article <mailman.9.1087331026.21521.python->,
<> 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,