在多线程程序中捕获标准输出

Question

I've got a function I need to call from a third-party library which I can't control. That function evaluates a command I pass in and prints its results to stdout . In my use case, I need to capture the results into a std::string variable (not write to a file), which I can do just fine in a single-threaded example:

int fd[2];
pid_t pid;

char *args[] = {};
if ( pid == 0 )
{
    dup2( fd[1], STDOUT_FILENO );
    close( fd[0] );
    close( fd[1] );

    char *args[] = {};

    // This func will print the results I want to stdout, but I have no control over its code.
    festival_eval_command("(print utt2)");

    execv( args[0], args );
}

close( fd[1] );
char buffer[1000000];
ssize_t length = read( fd[0], buffer, sizeof(buffer) - 1 );
std::string RESULT = buffer;
memset(buffer, 0, sizeof buffer); // clear the buffer

// RESULT now holds the contents that would have been printed out in third_party_eval().

Some constraints/detail:

• My program is multi-threaded, so other threads may be using stdout simultaneously (my understanding is that C++ ties the output from multiple threads into stdout )
• The third-party library is Festival , an open-source speech synthesis library written in LISP (which I have no experience in). I'm using its C++ API by calling: festival_eval_command("(print utt2)");
• festival_eval_command appears to use stdout , not std::cout (I've tested by redirecting both in a single-threaded program and only the stdout redirection captures the output from utt2 )
• As far as I can tell from the source, festival_eval_command doesn't allow for an alternate file descriptor.
• This function is only being run in one of the threads of my multithreaded program, so I'm only concerned about isolating the festival_eval_command output from the other threads' stdout .

My question: Is there a way I can safely retrieve the just results of festival_eval_command() from stdout in a multi-threaded program? It sounds like my options are:

• Launch this function in a separate process, which has its own stdout . Do the IO redirection in that separate process, get the output I need and return it back to my main program process. Is this correct? How would I go about doing this?
• Use a mutex around the festival_eval_command . I don't quite understand how mutexes interact with other threads though. If I have this example:

void do_stuff_simultaneously() {
    std::cout << "Printing output to terminal..." << std::endl;
}

// main thread
void do_stuff() {
    // launch a separate thread that may print to stdout
    std::thread t(do_stuff_simultaneously);

    // lock stdout somehow

    // redirect stdout to string variable
    festival_eval_command("(print utt2)");

    // unlock stdout
}

Does the locking of stdout prevent do_stuff_simultaneously from accessing it? Is there a way to make stdout thread-safe like this?

Answer 1

However, my program is multi-threaded, so other threads may be using stdout simultaneously

The outputs of threads are going to be interleaved in a fashion you cannot control. Unless each thread writes its entire output using one std::cout.write (see below for why).

Is there a way I can safely retrieve the just results of third_party_eval() from stdout in a multi-threaded program?

Each thread must run that function in a separate process, from which you capture its stdout into a std::string s (different one for each process).

Then in parent process you write that std::string into stdout with std::cout.write(s.data(), s.size()) . std::cout.write locks a mutex (to protect itself from data race and corruption when multiple threads write into it in any way, including operator<< ), so that the output of one process is not interleaved with anything else.

Answer 2

Note up front: This shows why globals are often a bad idea! Even more, library code (ie code intended for re-use in different contexts) should never use globals. This is also something to tell the supplier of that code, they should fix their library to provide a version that at least takes an output filedescriptor instead of writing to stdout .

Here's what I would consider doing: Move the whole function execution to a separate process. That way, if multiple threads need to run it, they will start separate processes with separate outputs that they can process independently.

An alternative way is to wrap this single function. This wrapper does all the IO redirection and it (being a critical section) is guarded by a mutex, so that two threads invoking the wrapper will be serialized. However, this has downsides, because in the meantime, that code still messes with your process' standard streams (so a stray call to output something would be mixed into the function output).

A second alternative is to put the function into a wrapper process who's only goal is to serialize the use of the function. You'd start that process on demand or on start of your application and use some form of IPC to communicate with it.