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 ? _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc