Detecting death of spawned process using Window CRT

Executive summary: I need a way to determine whether a Windows process I've spawned via _spawnl and am communicating with using FDs from _pipe has died.

Details:

I'm using the low-level CRT function in Windows (_eof, _read) to communicate with a process that was spawned via a call to _spawnl (with the P_NOWAIT) flag. I'm using _pipe to create file descriptors to communicate with this spawned process and passing those descriptors (the FD #) to it on the command line.

It is worth mentioning that I don't control the spawned process. It's a black box to me.

It turns out that the process we are spawning occasionally crashes. I'm trying to make my code robust to this by detecting the crash. Unfortunately, I can't see a way to do this. It seems reasonable to me to expect that a call to _eof or _read on one of those descriptors would return an error status (-1) if the process had died.

Unfortunately, that isn't the case. It appears that the descriptors have a life of their own independent of the spawned process. So even though the process on the other end is dead, I get no error status on the file descriptor I'm using to communicate with it.

I'v开发者_JAVA百科e got the PID for the nested process (returned from the _spanwnl call) but I don't see anything I can do with that. My code works really well except for one thing. I can't detect whether the spawned process is simply busy computing me an answer or has died.

If I can use the information from _pipe and _spawnl to determine if the spawned process is dead, I'll be golden.

Suggestions very welcome.

Thanks in advance.

UPDATE: I found a fairly simple solution and added it as the selected answer.

See How to know child process status and resource usage on windows?

You can just use WaitForSingleObject on the handle returned from spawnl; it's working fine for me. It sounds like you might have already tried this, but maybe I'm misunderstanding your responses.

Sample code that spawns a process and waits for it to finish without using _P_WAIT:

HANDLE hProcess = (HANDLE) _spawnl(_P_NOWAIT, "slave.exe", "slave.exe", NULL);
while(1)
{
  Sleep(100);
  if (WaitForSingleObject(hProcess, 0) == WAIT_OBJECT_0)
  {
    break;
  }
}

You'll have to move up the food chain if you want to be able to detect that the process exited. The native CreateProcess() Win32 API can give you back a HANDLE, you can use it in the WaitForSingleObject() API to wait or test if the process has exited. If you can get the PID, you can use OpenProcess() to get the HANDLE you need.

Another approach is to use _P_WAIT to make it a synchronous call. That will require a thread.

Thanks to nobugz for lots of good advice. I didn't end up taking his route of "moving up the food chain" so I'm writing this up as a separate answer but it is very much the result of his feedback.

I used my existing call to spawnl. It turns out this was possible because when called with the P_NOWAIT mode the return value is actually the same as OpenProcess. This is confusing because spawnl has a return type of intptr_t whereas OpenProcess has a return type of HANDLE. But they are equivalent (at least based on my testing).

Knowing this, I still wasn't out of the woods. I needed a reliable way to determine if the process was still running. All the various calls I made using the process handle (e.g. GetModuleBaseName) succeeded even when the process was dead.

Ultimately, I resorted to calling GetProcessId (with my process handle) to get the process ID and then calling EnumerateProcesses and digging through the results returned from it to see if any of those running processes shared the same process ID.

I would acknowledge that using higher level APIs (as nobugz suggested) is probably the way to go in general. In my case, I already had all the code working and only needed to determine if the nested process was still running so I took a minimalist approach.

Thanks again to nobugz for all the helpful suggestions.