Is the program you're calling from popen generating any output on stdin/stdout or waiting for input on stdin? Then there's a good chance it's blocked and nothing happens.... so consider redirecting stdin/stdout/stderr to /dev/null prior to calling the program out of popen, or read/write the needed information from the process you are calling. In contrast, the system() call will block the program it's executing out of, but will blast it's I/O to that of the calling program. Popen sends that input/output specifically to a pipe,and it needs to be read/written to complete.
Also, consider what's actually happening when calling popen or system -- a fork/exec (vfork usually). This may not be give the expected results with multithreaded programming unless particular care is taken. ( http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1287160467420+28353475&threadId=1438257 ) You're probably better off doing this kind of programming entirely event-driven, without any use of threads. Instead of fork/exec, have a subprocess that is basically a shell. Send text to it corresponding to the program you want to execute, and then select() for activity on the file descriptor which is either the program waiting for input or generating output. Parse the output to determine if the program has completed successfully, but do all of the processing asynchronously and without blocking. Basically this ends up being a state machine driven by the outputs (events) of the subprocesses being executed, without ever blocking to await program completion. This is the sort of thing best done by http://www.nist.gov/el/msid/expect.cfm or the equivalent functionality in python. Or the asynchronous subprocess facilities of WINTERP ( http://nielsmayer.com/winterp/doc/winterp.txt ), etc. Niels http://nielsmayer.com _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev