Issue1045748
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-10-12 21:58 by tim.peters, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (7) | |||
---|---|---|---|
msg22659 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-10-12 21:58 | |
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. |
|||
msg22660 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-10-12 22:37 | |
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. |
|||
msg22661 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-10-13 04:12 | |
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. |
|||
msg22662 - (view) | Author: Peter Åstrand (astrand) * | Date: 2004-10-13 07:30 | |
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. |
|||
msg22663 - (view) | Author: Anthony Baxter (anthonybaxter) | Date: 2004-10-13 15:04 | |
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. |
|||
msg22664 - (view) | Author: Fredrik Lundh (effbot) * | Date: 2004-10-13 15:26 | |
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. |
|||
msg22665 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-10-13 15:54 | |
Logged In: YES user_id=31435 Closing this now, since all the issues mentioned reached satisfactory resolutions. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:07 | admin | set | github: 41009 |
2004-10-12 21:58:02 | tim.peters | create |