Is pthread_create() after a fork() fixable in the uClibc ?

Jean-Christian de Rivaz jc at eclis.ch
Thu Dec 22 01:25:52 UTC 2011


As more I use the uClibc in systems, as more I face this old and known 
problem. For reference it was known at least in 2007

http://lists.uclibc.org/pipermail/uclibc/2007-June/038936.html

Obviously, even if it is arguable that the OpenGroup standard don't 
define this case, more and more situations in the real world fall into 
this. In one of the system we currently designed, we have 5 completely 
unrelated applications that hang because of this. Some can be fixed 
easily, but other cannot because of some complex relation between libraries.

Just an simple example: current Buildroot provides GVFS package that can 
support a FUSE mount if the libfuse package is selected. The gvfsd 
daemon start automatically the gvfs-fuse-daemon that use 
pthread_create(). But gvfs-fuse-daemon, before calling pthread_create(), 
call the libfuse that call uClibC daemon() that internally call fork(). 
This end up to the pthread_create() after a fork() situation that simply 
hang the process. Now, you can't blame libfuse for using daemon() and 
you can't blame gvfs-fuse-daemon for using libfuse and pthread_create(). 
In addition, gvfs-fuse-daemon really have to call the libfuse library 
before pthread_create() because this is into a callback from the library.

Others common case where this hang is at the startup of the system, when 
some multithreaded application are demonized. This can be really 
annoying in case this is not open source code...

It's difficult to scope this problem. I have see new programmer lost 
days without having a clue about what can be false. I myself lost the 
past two days adding debug in gvfs and libfuse before I started to 
understand.

The drama is that, even if the situation is not defined by the 
OpenGroup, it actually work perfectly well with the glibc or the eglibc, 
so that nobody care to fix it. More en more applications uses pthread. 
And fork() without exec() just after it, like daemon(), is not going to 
disappear by magic.

So without starting a endless thread about the interpretation of the 
standards, my motivation with this post is to collect as much 
information as possible on the technical details that make the others 
libc able to do pthread_create() after fork() and why uClib can't. The 
hope is that an acceptable change in the uClibc can be found to improve 
this.

Jean-Christian


More information about the uClibc mailing list