Re: [PATCH] Fix gc.test "after-gc-hook gets called" failures

[Mark H Weaver <mhw@netris.org>]

Hi Andrea,

Andrea Azzarone <azzaronea@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.azzarone@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