GNU bug report logs - #31878
Module autoloading is not thread safe

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31878 <at> debbugs.gnu.org
Subject: bug#31878: Module autoloading is not thread safe
Date: Thu, 23 Aug 2018 15:54:00 +0200

Mark H Weaver <mhw <at> netris.org> skribis:

> I forgot to mention an important aspect of the proposed auto-load
> locking here.  It would not be a global lock, but rather a lock specific
> to the module being loaded.  So, I guess we would need a global table of
> locks for modules-being-loaded.

Right (we can’t add a mutex to the module record without breaking the
ABI.)

> Since Guile (unfortunately) allows cyclic module dependencies, we would
> need a mechanism to avoid deadlocks in case modules A and B both import
> each other, and two threads concurrently attempt to load those modules.
>
> The first idea that comes to mind is to also have a global structure
> storing a partial order on the modules currently being loaded.  If,
> while module A is being loaded, there's an attempt to auto-load module
> B, then an entry (A < B) would added to the partial order.  The partial
> order would not allow cycles to be introduced, reporting an error in
> that case.  In case a cycle would be introduced when adding (A < B),
> then the thread would simply be given access to the partially-loaded
> module B, by adding B to its local list of modules-being-loaded.

Would it enough to (1) use recursive mutexes, and (2) have
‘resolve-module’ lookup modules first in the global name space, and
second in the local list of modules being loaded?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.