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

[Khem Raj]

On (22/12/11 02:25), Jean-Christian de Rivaz wrote:
> 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.


Do you see it when you use NPTL for pthread as well ?