1

If I have a pipe to run some command, the piped command needs to do some cleanup, however, if the processes that started the pipe has an error, the piped command is not cleaning up. Is the piped command getting SIGPIPE in this case? How can I ensure cleanupPipe destructor is always run? When the errorOccurred exception is thrown, I am seeing that cleanupPipe destructor is not run. I have SIGPIPE handler set up to throw an exception, so if SIGPIPE is the result, I would expect my destructor to be run when the SIGPIPE results in thrown exception unwinding the stack.

void
testCase() {
  class cleanup {
  public:
    cleanup(FILE *pipe)
      : _pipe(pipe) {
    }
    ~cleanup() {
      ::pclose(_pipe);
    }

  private:
    FILE *_pipe;

  };

  string cmd("runMyCommandImplementationHere argsHere");
  FILE *pipePtr = ::popen(cmd, "w");
  cleanup cleanUpPipe(pipePtr);

  // Normally, write data to pipe until process in pipe gets all the data it
  // needs and exits gracefully.
  for (;;) {
    if (someErrorOccured()) {
      // When this error occurs, we want to ensure cleanupPipe is run in piped
      // process.
      throw errorOccurred(status);
    }
    if (finishedWritingData()) {
      break;
    }
    writeSomeDataToPipe(pipePtr);
  }
}

void
myCommandImplementationHere() {
  class cleaupPipe {
  public:
    cleanupPipe(const string &filename)
      : _filename(filename) {
    }
    ~cleanupPipe() {
      ::unlink(_filename.c_str());
    }

  private:
    string _filename;

  };

  string file("/tmp/fileToCleanUp");
  cleanupPipe cleanup(file);

  doSomeWorkOnFileWhileReadingPipeTillDone(file);
}
WilliamKF
  • 41,123
  • 68
  • 193
  • 295

1 Answers1

3

Throwing an exception in a signal handler is a very bad idea. Signal handlers must be asynchronous-safe. To make matters worse, signal handlers run in which is essentially a different thread of execution than your mainline code. It is best to keep your signal handlers small and very primitive. For example, make the SIGPIPE handler set some volatile global variable that indicates that SIGPIPE occurred and test for that as an error condition in your mainline code.

A couple of other comments:

  • You should check the return status when dealing with C functions such as popen, pclose, and write. You aren't doing so on your call to popen or pclose, at least not in the sample code.
  • Why the asymmetry in class Cleanup? The constructor receives an already-constructed FILE pointer, but the destructor destroys it via pclose. IMO it would be better if the constructor calls popen, taking the command string as an argument to the constructor.

Addendum
Perhaps even better than creating a handler for SIGPIPE that sets some global variable is to set the handler for SIGPIPE to ignore, and then check for an EPIPE error from your writes to the pipe.

David Hammen
  • 32,454
  • 9
  • 60
  • 108
  • Ah, I totally missed that he was throwing from the signal handler. – Eugene S Aug 07 '11 at 15:25
  • So are you saying the pclose() will definitely cause a SIGPIPE? I've made SIGPIPE ignored, but the destructor is still not being called, so that makes me think some other signal is happening or else I would expect the destructor to have run and deleted the temporary file. – WilliamKF Aug 07 '11 at 23:19
  • "So are you saying the pclose() will definitely cause a SIGPIPE?" No! Calling `pclose()` closes the connection to the process started by `popen()` and waits for that process to terminate. `pclose()` will not cause a SIGPIPE in your application. A SIGPIPE occurs when the process started by `popen()` terminates prematurely, where "prematurely" means that you application is still trying to write to the pipe. – David Hammen Aug 08 '11 at 15:11
  • Okay, so why is the process started by `popen()` not running destructors? My main issue is I need a way to guarantee the destructors get run and the temp file deleted. – WilliamKF Aug 08 '11 at 18:23
  • @DavidHammen Note it is the reading end of the pipe which is not cleaning up, can a reader get SIGPIPE or only a writer? – WilliamKF Aug 14 '11 at 02:44
  • @William: If the writing end of a pipe disconnects all that happens at the reading end is that the reader gets an end of file indicator when it tries to do a read. That is exactly the desired behavior, so there's no problem with this scenario. Problems arise when the reader disconnects before the writer does. Suppose the reader terminates prematurely, where "prematurely" means the writer still has stuff to send down the pipe. The writer will get a SIGPIPE when it tries to write to its side of the pipe. Think of SIGPIPE as the mechanism by which the writer is informed that nobody is listening. – David Hammen Aug 14 '11 at 04:18
  • Resolved the issue, it was coding error due to calling exit() and thus destructors were not being called. – WilliamKF Aug 14 '11 at 11:57