I would like to write a program in C that forks then execs three different processes.

Afterwards, two of the programs will be suspended and only one of the three will be outputting to stdout. Is is possible to later on suspend the process currently running on stdout, resume one of the other suspended processes and have that displayed on stdout instead?

  • Does this answer the mail? geeksforgeeks.org/condition-wait-signal-multi-threading You basically need a way to signal the other process that you are done so that it can wake up and resume processing. – Berin Loritsch Feb 11 at 13:52
  • Hi. Thanks for answering. I actually don't have any experience multi-threading, but this looks helpful and is probably what I'm looking for. – user942937 Feb 11 at 16:18

Yes. If you're on a POSIX-ish system and have the PIDs of the child processes you can send them signals like SIGSTOP to suspend or SIGCONT to continue their execution. It is fine if multiple processes share a file descriptor like stdout.

However, if you want to run all child processes concurrently but switch the stdout between these processes, you can't do that directly. Instead, you need to redirect the stdout of each child process to a separate file handle and buffer their contents in another process that then decides what to print to the original stdout.

  • Hi. Thanks for answering. Would sending something like SIGSTOP to one then SIGCONT to another change the process currently being displayed to stdout? How do multiple processes share a file descriptor like stdout? Using the PIDs of the processes, how do I pipe the output from one process to stdout then have the program swap it with another process on command? – user942937 Feb 11 at 16:28
  • @user942937 These signals do not affect which process is connected to stdout (they all are). Instead, these signals change whether the process is running. It is possible to have multiple processes running at the same time that all print to stdout, so that their output will be interleaved. Maybe the best way to learn this is to play around a bit in the Bash shell: the & operator can run processes in the background, like (echo A before; sleep 2; echo A after) & (echo B before; sleep 1; echo B after) & – amon Feb 11 at 16:41
  • So it seems this is the simplest answer. Does the second solution have any advantages over the first? – user942937 Feb 11 at 16:46
  • 1
    @user942937 The two approaches are completely different. Only running one process at a time has zero overhead, but just runs one at a time. If you want to run multiple processes in parallel then you need an extra process that buffers their output and prints it in some order. For example, the GNU Parallel software does exactly that and has different options for buffering the output, see its manpage. – amon Feb 11 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.