waitpid problems: new insights ...

After some days of struggling with this problem, I found out that the 
reason was my attempt to handle a child process created via 
system("bla") with waitpid().

In the (e.g. bsd) man pages for waitpid() I could not fin any hint that 
the (synchronous) system() is not handled by waitpid(). The 
implementation by EMX makes things a bit different: system() boils down 
to a call of DosExecPgm() with execFlag=EXEC_SYNC. waitpid() is 
basically a call to DosWaitChild() (BTW: do you think EMX's waitpid() 
honours the WNOHANG flag as described in the docs....?). And here the 
OS/2 toolkit reference states unambigously:

2 EXEC_ASYNCRESULT
Execution is asynchronous to the parent process. When the child process 
ends, its result code is saved for examination by a DosWaitChild 
request. The process ID is stored in the codeTerminate field of the 
RESULTCODES structure pointed to by pRes.

And for DosWaitChild:

DosWaitChild waits for completion of a child process whose execution is 
asynchronous to that of its parent process. The child process is created 
by DosExecPgm with a value of 2 specified for execFlag.

So this means: EMX cannot handle children created by calling system() 
with waitpid() (before somebody asks: e.g. in a signal handler for 
SIGC(H)LD, which is called when system() returns: sample code on 
request). The effect is that the signal simply does not go away: 
waitpid() returns again and again with ret code 0 and the same pid if 
called in a while(...) loop:

  while ((pid=waitpid(-1, &status, WNOHANG))>0 || (pid<0 && errno==EINTR)) {
    printf("bury dbg : %i - %i -%i\n",dct++,pid,status);
  }

--> (at the top the tail of a process list from Theseus: and no, this 
does not only happen for this very PID ;-))

665 69 2 WPIDEMIN
666 665 2 SH
667 666 2 SH
669 667 1 CMD
SIGCLD: buryChild called
bury dbg : 0 - 666 -0
bury dbg : 1 - 666 -0
bury dbg : 2 - 666 -0
bury dbg : 3 - 666 -0
bury dbg : 4 - 666 -0


Do YOU have ideas how one could work around this?

Thomas.

-- 
Thomas Hoffmann                                    
[email protected]                                       Dresden, Germany

..sig under construction ... (not really)