Hi,

No problem. :-) I've attached a pure pthreads version:

$ gcc -o test -lpthread -lpipeline main.c
$ ./test
PRODUCED SOME WORK
PRODUCED SOME WORK
PRODUCED SOME WORK
CONSUMED SOME WORK
PRODUCED SOME WORK
CONSUMED SOME WORK
PRODUCED SOME WORK
./test: waitpid failed: No child processes

Thanks for working on this, libpipeline rocks.

(file #24029)

Hi,

Thanks for the followup! As you may have noticed, I was able to work around it by forking in synconv, so now I'm 100% sure the race in libpipeline is the culprit. :-)

I'm attaching a very minimalistic test case. To build it, you'll need:

• cmake + pkg-config
• libboost-dev
• libboost-thread-dev

Then you can run:

$ cd /path/to/extracted
$ mkdir build
$ cd build
$ cmake ..
$ make
$ ./test
PRODUCED SOME WORK
PRODUCED SOME WORK
PRODUCED SOME WORK
CONSUMED SOME WORK
PRODUCED SOME WORK
./test: waitpid failed: No child processes
test: /usr/include/boost/thread/pthread/mutex.hpp:47: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed.
Aborted

Please disregard the boost::mutex assertion, it's probably related to the static initialization of mutexes + my abort() call.

Since this is a classic race condition, you may not be able to reproduce it consistently. Here, with a 2-core CPU, I've been able to reproduce it every time after 3 or 4 seconds. You may want to tune NUM_THREADS to make it easier to reproduce on your machine.

Please let me know if you want it converted to pure pthreads (or even pure C), shouldn't be too hard. Also, please let me know of anything else you'd think could be helpful.

Thanks in advance,

(file #24022)

Hi,

I'm facing some thread-safety issues in my libpipeline-based project[1], which I think are related to libpipeline. It looks like pipeline.c uses static variables and messes with the process signal mask. It might be possible to use pthread_sigmask and make those static variables thread-local.

At least pipeline_wait_all and the signal handlers should be made thread-safe. If the setting up of the pipeline would remain thread-unsafe, it wouldn't be a big deal.

So, what do you think? Is there a workaround you can think of? Is it always necessary to handle SIGCHLD? As far as I know, if you ignore SIGCHLD, your children won't become zombies anymore in Linux/BSD.

In synconv, we use libpipeline to create the transcoding pipeline (say, decoding with flac and encoding with lame). So we launch N different threads for each of the files that need to be transcoded. The threads block on pipeline_wait. If I use more than a single thread, I occasionally get an error message such as:

synconv: waitpid failed: No child processes

If you think going with TLS and maybe a lock or two isn't the way to go, I think I'll have to fork into another process to use libpipeline.

Thanks,

[1]: https://github.com/fernandotcl/synconv