Dan Nelson wrote: >In the last episode (Nov 04), Marc Ramirez said: > > >>On Thursday 04 November 2004 09:36 am, Mike Makonnen wrote: >> >> >>>Hmm, looks like the application is using libthr and not libpthread. >>>I'll take a look at it, but in the mean time you might want to map >>>libthr and libc_r to libpthread in libmap.conf(5). >>> >>>Can all other users with this problem verify which threading >>>library they're running? You can use the following command on the >>>binary. For example: # ldd /path/to/binary >>> >>> >>Not me. Thanks! >> >> > >I just noticed this on my machine as well (SMP, 5.3-stable as of >yesterday), running a testsuite program linked to libpthreads. It >creates 10 threads whose only job is to fork(), exec /bin/sleep, kill >-9 the child, and wait for the status. Each thread does this 1000 >times in a tight loop. Occasionally the whole thing will end up >STOPped, but resumes within 60 seconds. If I ktrace the process during >this, I see a long delay followed by: > > 39117 pike RET fork 0 > 32592 pike RET fork 39117/0x98cd > >Could there be a race or deadlock within the kernel's fork() routines? >What happens if two threads on different CPUs decide to fork at the >same time? > fork is supposed to go into "single threading" mode, where only the thread that is running fork() is running, until it completes. All other threads are temporarily "suspended" until the thread finishes the fork, and it will not proceed into the fork() until it has confirmed that they ARE suspended. David Xu just fixed a small bug in this however, so get latest kern_thread.c (1.205) and try again. this code is common to libthr and libpthread. > > >Received on Thu Nov 04 2004 - 21:35:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:21 UTC