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
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
