0

I have code where I want to encapsulate a particular piece of code into a forked child so that if the code causes issues, it will not affect the parent and the parent will be able to report.

I am not execing after the fork call. Just plain fork and then the code runs that would have normally run in the parent.

The code in the child outputs stuff to stdout and stderr. Due to issues with interleaving output and stdio buffering, I was now looking into TLPI for a better solution.

The idea I came up with was roughly:

  • pipe() for each stream
  • fork()
  • in child:
    • close() read end of pipes
    • dup2() the write ends onto the file descriptors for stdout and stderr respectively
    • setbuf(fd, NULL) to turn off stdio stream buffering inside the child.
  • in parent:
    • close() write ends of pipes
    • use select/pselect/epoll etc (has to run across Linux, BSDs, AIX, Solaris etc) to watch the read ends of the pipes for new data and when it arrives write() it straight to the respective file descriptors in the parent process.

Now, I presume there is one step missing between the dup2 and the setbuf inside the child. What is it?

setbuf takes a FILE* whereas of course dup2 acts on int.

freopen came to mind, but it requires a path. If I merely want to assign a new fileno to the streams, how can I do that?

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152

1 Answers1

1

The extern variables stdin, stdout and stderr are FILE * pointers. You can pass these to setbuf / setvbuf. However, note that the child has a separate address space so whilst it will inherit the state of the buffers at the time of the fork(), both can continue to use the buffers safely, and if you fflush STDOUT and STDERR, the output buffers will be empty anyway.

This is the way I would do it in the child (untested, and please do add some error handling):

void
child ( ... )
{
  const char *devnull = "/dev/null";

  /* turn off buffering */

  setvbuf (stdin, NULL, _IONBF);
  setvbuf (stdout, NULL, _IONBF);
  setvbuf (stderr, NULL, _IONBF);

  for (i = getdtablesize () - 1; i >= 0; i--)
    {
      if ((i != write_end_of_pipe1) && (i != write_end_of_pipe2))
        close (i);
    }

  i = open (devnull, O_RDWR);
  if (i == -1)
    {
      fprintf (stderr, "Unable to open /dev/null\n");
      return;
    }

  i = open (devnull, O_RDONLY);
  if (i != 0)
    {
      dup2 (i, 0);
      close (i);
    }

  dup2 (write_end_of_pipe1, 1);
  close (write_end_of_pipe1);

  dup2 (write_end_of_pipe2, 2);
  close (write_end_of_pipe2);

  return;
}
abligh
  • 24,573
  • 4
  • 47
  • 84
  • Thank you. I know they are `FILE*` and I even mentioned that. The question, however, remains whether after using `dup2()` to replace `STDERR_FILENO` and `STDOUT_FILENO` I'll have to reopen `stderr` and `stdout` respectively before `setbuf` or not. – 0xC0000022L Apr 03 '14 at 13:38
  • No you won't. `glibc` is going to be blindly writing to / reading from FDs 0, 1 and 2. So the fact you've closed and reopened them is irrelevant. So long as the new file has the right FD and the right permissions (`O_RDONLY` or `O_WRONLY` as appropriate), you can do what you like. But obviously get it done before you need to do STDIO next. – abligh Apr 03 '14 at 16:18
  • thanks, I'll accept for now. I cannot rely merely on the behavior of glibc, though, since I have half a dozen different C runtimes to cover. – 0xC0000022L Apr 04 '14 at 13:06
  • I believe it's completely standard rather than glibc specific, and I've been doing it since before `glibc` existed. Certainly older `libc` used to do it. I can't see how else stdio would work to be honest. – abligh Apr 04 '14 at 16:23
  • I guess I'll notice whenever it's not the case, so there goes the upvote. Thanks for your help. – 0xC0000022L Apr 04 '14 at 19:16