1

I'm a little overwhelmed by how many ways you can control processes, like wait() pause() signal handling etc. All I want is to resume a paused process, and execute the line after the pause() statement afterward, like so:

/* Child code */
pause();
execvp(args[index], args);

The topology of my processes is linear children. One parent, n children, no grandchildren. So after the parent finishes forking, I have it running this loop to try to wake them up in order:

// Parent iterates through n child processes
for (i = 0; i < n; i++) {
    // Need to unpause here, do i need signals?
    signal(SIGCONT, sighandler);        
    // I don't know what im doing
}
wait(&status);

I can get their process IDs if that helps, but I dont know what to do with them.

Otay
  • 21
  • 2
  • 8
  • Side note: The [`wait`](http://man7.org/linux/man-pages/man2/waitpid.2.html) function will only wait "until one of its children terminates". That means that you'll only be waiting for the fastest child to exit, though you may have many. – Addison Jul 25 '17 at 05:28

1 Answers1

2

From the pause(2) man page (emphasis mine):

pause() causes the calling process (or thread) to sleep until a signal is delivered that either terminates the process or causes the invocation of a signal-catching function.

And more specifically:

pause() only returns when a signal was caught and the signal-catching function returned.

This means that for your child to unpause, you need to send it a signal (and probably a custom signal handler).

This is a simple signal handling function - Usually these are put at the top of your page (under the imports) or in the header file.

void handleContinueSignal(int sig) {
    myGlobalStaticContinueVariable = 1; // Or some other handling code
}

And this is how you announce that your signal handling function should be associated with the SIGCONT signal, should it ever be received. You'll probably only want your child process to run this line. Make sure you put it in before the pause though - getting signal handlers running is one of the first things that a new process should do.

signal(SIGCONT, handleContinueSignal); // Name of the signal handling function

Finally, you can make your parent send a SIGCONT signal to the child by giving its PID like this:

kill(yourChildPID, SIGCONT);

For your code, you'll have to make the parent loop though and call this once for each child's PID, which will wake each of them up in turn.

Addison
  • 7,322
  • 2
  • 39
  • 55
  • 1
    `printf` should not be called from within the signal-handler. Instead set a *flag* and call `printf` outside the handler based on the flag. See [**How to avoid using printf in a signal handler?**](https://stackoverflow.com/questions/16891019/how-to-avoid-using-printf-in-a-signal-handler) – David C. Rankin Jul 25 '17 at 05:15
  • Always good practice. Note, I understood you and that the `printf` was just a way to show that the signal was caught and wasn't intended as an integral part of the handler -- but it was worth a comment and no ding `:)` – David C. Rankin Jul 25 '17 at 05:18
  • Is there a way to use PIDs in the signals to specify which one I want unpaused? I guess I'm having a really hard time understanding how the signals are sent and received – Otay Jul 25 '17 at 05:23
  • If I were you, then I'd make an array of all of the children's PID's. That way you can loop through and send a `SIGCONT` to each of them, or every second one, etc – Addison Jul 25 '17 at 05:25
  • yeah that sounds like what I want, but I dont understand how to specify who gets the signal. Will my signal be sent to all children or a specific one? Do I need the signal to somehow specify the PID if it goes out to all of them at once to distinguish who its meant for? – Otay Jul 25 '17 at 05:34
  • When you send a signal you have to specify which Process ID (PID) it is intended to be sent to. Your signal will only be received by the child which you send it to. – Addison Jul 25 '17 at 05:36
  • Wait does that mean "kill" sends a non terminating signal? wowww that is a totally obnoxious misnomer. – Otay Jul 25 '17 at 05:43
  • `kill` is a somewhat misleading name in this scenario, but it's also quite accurate - I could be mistaken, but I think that any signal kills a process when left unhandled. – Addison Jul 25 '17 at 05:47