On Fri, Feb 17, 2017 at 11:06 PM, Mark Geisert <m...@maxrnd.com> wrote: > Erik Bray wrote: >> >> On Tue, Feb 14, 2017 at 8:25 PM, Mark Geisert <x...@xxxxxx.xxx> wrote: > > > Please don't quote raw email addresses. We try to avoid feeding spammers.
Sorry--normally replies on this ML are just back to the ML itself (my preference as well) so I wasn't expecting it. >>> Erik Bray wrote: >>>> >>>> >>>> The attached Python script >>> >>> >>> ?? >> >> >> D'oh! Here is the script. It at least demonstrates the problem. >> > [...] > > Thanks! Running this script repeatedly on my system (Win7, 2 cores / 4 HT > threads) showed no differences between your Test 1 and Test 2. Each Test > concludes in one of three ways, seemingly randomly: (1) read of > /proc/<pid>/stat succeeds and process status is displayed, (2) read fails > with Python IOError, (3) read apparently succeeds but there's no process > data displayed. > > An strace of your script shows Python itself is calling wait4() to reap the > child process. So, as Doug suggested on another thread, the script's > actions are just subject to the whims of process scheduling and vary from > run to run. You're right. The first time I was testing this, for whatever reason, I was getting *very* consistent results. Test 1 *always* succeeded and test 2 always fails. But trying it now, I am getting similar results. What I was going by was the docs for ExitProcess [1] which states: "Exiting a process does not necessarily remove the process object from the operating system. A process object is deleted when the last handle to the process is closed." So my guess was that Cygwin might try to hold on to a handle to a child process at least until it's been explicitly wait()ed. But that does not seem to be the case after all. Anyways, I think it would be nicer if /proc returned at least partial information on zombie processes, rather than an error. I have a patch to this effect for /proc/<pid>/stat, and will add a few more as well. To me /proc/<pid>/stat was the most important because that's the easiest way to check the process's state in the first place! Now I also have to catch EINVAL as well and assume that means a zombie process. Thanks, Erik [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
