[ python-Bugs-1045748 ] test_subprocess vs Windows

[SourceForge.net]

Bugs item #1045748, was opened at 2004-10-12 23:58
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045748&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Fredrik Lundh (effbot)
Summary: test_subprocess vs Windows

Initial Comment:
Some glitches.

This takes about a minute and 20 seconds to run on a 
3.2 GHz WinXP Pro SP2 box w/ a gigabyte of RAM.  
That's waaaaay slow.  Don't know whether it's a bug or 
a feature.  If it's a feature, changes to regrtest should 
be made so this only runs when a new "resource" is 
specified.

At one point, it prints "banana" to the DOS box running 
the tests.  Extraneous output shouldn't happen.  Again 
don't know whether this is intended, but it's a bug either 
way.

Would be better if it didn't pop up a visible DOS box 
while it's running.

As Barry noted, the test fails in a debug build.

----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2004-10-13 09:30

Message:
Logged In: YES 
user_id=344921

>The test popping up a DOS box is test_creationflags().  
>Maybe that's what it's supposed to do.

Yes, it's supposed to do that. I couldn't come up with any
better creationflag to test than CREATE_NEW_CONSOLE. (The
list of valid flags is on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/process_creation_flags.asp
) Of course, one possibility is to remove this test altogether. 

>By far the biggest time hog is test_no_leaking(), which 
>creates >= 1026 processes.  That's very expensive under any 
>flavor of Windows.  Since it doesn't actually appear to test 
>or leaks, maybe it could be cut to one iteration with no real 
>loss of functionality <wink>.

Normally, you cannot have 1026 files open in a UNIX process.
So, this test makes sure all used file descriptors are
closed properly. This test has actually found bugs for me
during the development. I'm not sure if Windows has a
limitation of how many handles a process can have open, but
in any case, the test is a pretty good stress test. However,
since it takes so long, I suggest that we cut down the
number of iterations to 65 or so on Windows. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-10-13 06:12

Message:
Logged In: YES 
user_id=31435

I fixed all these except for test_no_leaking().  Left an XXX 
comment in the test about that one.  Don't understand it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-10-13 00:37

Message:
Logged In: YES 
user_id=31435

More info:

The test popping up a DOS box is test_creationflags().  
Maybe that's what it's supposed to do.

By far the biggest time hog is test_no_leaking(), which 
creates >= 1026 processes.  That's very expensive under any 
flavor of Windows.  Since it doesn't actually appear to test 
for leaks, maybe it could be cut to one iteration with no real 
loss of functionality <wink>.

test_stdout_none() is the one that prints "banana" to the 
screen.  Don't know whether it should.  If so, changing its 
output to, e.g., "This line is expected extraneous output." 
would be better.

That's it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045748&group_id=5470