Message168576
| Author |
jeremy.kloth |
| Recipients |
chris.jerdonek, georg.brandl, jeremy.kloth, ncoghlan, pitrou, sbt |
| Date |
2012年08月19日.14:32:26 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAGvrs3LhDztbCnirE3Ka_iHGDnMsH=WDRWL__cB0JBQ+GhiCaw@mail.gmail.com> |
| In-reply-to |
<1345372318.98.0.514391418726.issue15526@psf.upfronthosting.co.za> |
| Content |
> I think the reason that it is only this buildbot which fails is that the other Windows buildbots don't use multiple processes. Therefore they don't use a different dir for each test.
That might be it. Also the failure possibly only happens when
multiple builds are being run thus slowing down process creation and
termination.
> Would this cause a handle leak if os.waitpid() is not used?
It seems so, yes.
So to expand on #4:
4a) create a new handle type that closes the handles on dealloc
4b) return the process ID instead using GetProcessId() and callers
interested in waiting would then need to use _winapi.OpenProcess() to
convert it to a handle for os.waitpid() or
_winapi.WaitForSingleObject()
4c) add a third optional argument to os.startfile() "mode" that mimics
the mode semantics of the os.spawn*() functions |
|