Angus Leeming wrote: > John, I think that the bodies of these functions should be wrapped > inside sigprocmask calls so that the signal handler is not called > unexpectedly. (generateChild contains the fork, execvp code). > > Agree? > > Questions. > 1. In runBlocking, all SIGCHLD signals are blocked until after this > particular child has died and been reaped. Am I corect to say that > thereafter the signal handler will not receive a signal > corresponding to this particular child?
Answering myself: No, it does receive the signal. > 2. In runNonBlocking(), all SIGCHLD signals are blocked until after > we have performed some preliminary book-keeping in > ForkedcallsController::addCall. Am I correct to say that thereafter > the signal handler *will* receive a signal if the child failed to > start (failed execvp) but will not receive a signal if the fork > failed? This is correct. -- Angus
