Hello Mark, Thanks for chiming in! Mark H Weaver skribis: > Does libgc spawn threads that run concurrently with user threads? If > so, that would be news to me. My understanding was that incremental > marking occurs within GC allocation calls, and marking threads are only > spawned after all user threads have been stopped, but I could be wrong. libgc launches mark threads as soon as it is initialized, I think. > The first idea that comes to my mind is that perhaps the finalization > thread is holding the GC allocation lock when 'fork' is called. The > finalization thread grabs the GC allocation lock every time it calls > 'GC_invoke_finalizers'. All ports backed by POSIX file descriptors > (including pipes) register finalizers and therefore spawn the > finalization thread and make work for it to do. In 2.2 there’s scm_i_finalizer_pre_fork that takes care of shutting down the finalization thread right before fork. So the finalization thread cannot be blamed, AIUI. > Another possibility: both the finalization thread and the signal > delivery thread call 'scm_without_guile', which calls 'GC_do_blocking', > which also temporarily grabs the GC allocation lock before calling the > specified function. See 'GC_do_blocking_inner' in pthread_support.c in > libgc. You spawn the signal delivery thread by calling 'sigaction' and > you make work for it to do every second when the SIGALRM is delivered. That’s definitely a possibility: the signal thread could be allocating stuff, and thereby taking the alloc lock just at that time. >> If that is correct, the fix would be to call fork within >> ‘GC_call_with_alloc_lock’. >> >> How does that sound? > > Sure, sounds good to me. Here’s a patch: