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.

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.

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.

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. 

Logged In: YES 
user_id=29957

Er - sorry - do I misunderstand this? You're assuming that
we can get 1024 FDs, and have a test that relies on this?

Plenty of systems have lower limits by default, such as
HP/UX. Please remove this test, if this is going to break
these systems. (From memory, HP/UX defaults to 64 FDs, but
there are plenty of others with < 1024 FD limits)

If the test _does_ rely on being able to open 1024 FDs, it
should be removed.

Logged In: YES 
user_id=38376

No, it relies on being able to do something *without* leaking 
handles; the 1026 value was chosen to make sure we notice 
a leak, on a reasonable number of platforms.

Logged In: YES 
user_id=31435

Closing this now, since all the issues mentioned reached 
satisfactory resolutions.