in reply to Re^5: waitpid returns -1 for still running child (Windows)
in thread waitpid returns -1 for still running child (Windows)

I had meanwhile a second case of this effect, and analyzing the timestamps here, shows the following pattern:
  1. TIME 1: Child is started witch system(1,...)
  2. TIME 2: waitpid returns -1
  3. TIME 3: The child writes the first entry to its log
  4. TIME 4: The child writes the last entry to its log
The difference between the timestamps 4 and 1 is only 2 seconds, much less than in the first case. It is interesting here that the child seemed to start running after it had ended. Now we know that -1 returned by waitpid does not really mean "process has ended", but "process does not exist". The fact that it indicates an ended process is just my conclusion, since I had started it before. Could it be that there is some time gap between system(1,...) returning to the caller, and the child process being entered in the Windows process table? If the master process queries waitpid during this time, it would indeed get "process does not exist" and wrongly conclude that the child already terminated.

I don't have access to all the logs of the first case, where the time gap was 8 seconds - much longer than in the second case. However, in both cases, the tests run on a heavily loaded machine, so maybe this could be an explanation.

-- 
Ronald Fischer <ynnor@mm.st>

Replies are listed 'Best First'.
Re^7: waitpid returns -1 for still running child (Windows)
by BrowserUk (Patriarch) on Jul 07, 2010 at 14:49 UTC
    Could it be that there is some time gap between system(1,...) returning to the caller, and the child process being entered in the Windows process table?

    Um. I think not. For a definitive answer you would probably have to ask Dave, but as system pretty much translates into a simple call to CreateProcess(), it is hard to see how that would return to the caller before the created process existed within the system tables.

    However, it is conceivable that on a very heavily loaded system, that the process of creating a process, meant that the creating process overstayed its time slice, and so as soon as that calling process transitioned back from ring 0 to ring 3, it was immediately context switched, and did not get another time slice for 2 seconds. If sufficient other processes had become eligaible to run in the interim. But 8 seconds?

    That said. I have on occasion run a perl process to explore the limits of my system--for example, by requesting the allocation of a single 10 GB scalar (I only have 4GB of physical memory), and then got up and made myself a cup'o'char. On my return, if the system is still running like a dog, I've resorted to killing the process.

    Now, like Mr. Tipton grits, some things just take as long as they take. And unless you bought magic grits from the beanstalk salesman, you're just gonna have to wait till they're ready.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom