Hi Andrea, Andrea Azzarone <azzaro...@gmail.com> writes:
> "after-gc-hook gets called" test randomly fails as reported > downstream, for example: > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31776 > - https://bugs.launchpad.net/ubuntu/+source/guile-2.2/+bug/1823459 > > I'm attaching a patch that seems to fix the failures. > > From 2efba337d5b636cd975260f19ea74e27ecf0ca17 Mon Sep 17 00:00:00 2001 > From: Andrea Azzarone <andrea.azzar...@canonical.com> > Date: Thu, 11 Apr 2019 16:30:58 +0100 > Subject: Fix gc.test "after-gc-hook gets called" failures > > * libguile/scmsigs.c: Call scm_async_tick to give any pending asyncs a chance > to > run before we block indefinitely waiting for a signal to arrive. Thanks for this. I pushed your commit (with minor reformatting) to our 'stable-2.2' branch as commit 546b0e87294b837ec29164d87cf17102e9aeee0c. I believe that this will prevent the problem from happening in the most common cases, e.g. when there's only one user-visible thread, or when there are no long-sleeping user-visible threads. However, it occurs to me that in a multithreaded Guile program, a user thread might trigger a GC and then sleep for a long time, without calling 'scm_async_tick' in between. If we're unlucky and the 'after_gc_async' gets queued in the wrong thread, it might be a long time before the hook runs. Fundamentally, the problem we face here is similar to the thorny problems faced with finalizers and signal handlers: we must choose a proper time and context for them to be run safely, when the data they need to access is in a consistent state, etc. To deal with the issues around finalizers, Guile recently gained a finalizer thread. It may be that we should arrange to run the 'after_gc_async' in the finalizer thread as well, instead of whatever random thread we happen to be in when GC is triggered. Thoughts? Regards, Mark