Module system thread unsafety and .go compilation

[Taylan Ulrich Bayırlı/Kammer]

To speed up the compilation of the many Scheme files in Guix, we use a
script that first loads all modules to be compiled into the Guile
process (by calling 'resolve-interface' on the module names), and then
the corresponding Scheme files are compiled in a par-for-each.

While Guile's module system is known to be thread unsafe, the idea was
that all mutation should happen in the serial loading phase, and the
parallel compile-file calls should then be thread safe.

Sadly that assumption isn't met when autoloads are involved.
Minimal-ish test-case:

- Check out 0889321.

- Build it.

- Edit gnu/build/activation.scm and gnu/build/linux-boot.scm to contain
  merely the following expressions, respectively:

(define-module (gnu build activation)
  #:use-module (gnu build linux-boot))

(define-module (gnu build linux-boot)
  #:autoload   (system base compile) (compile-file))

- Run make again.

If you're on a multi-core system, you will probably get an error saying
something weird like "no such language scheme".

Note: when you then run make *again* it succeeds.


Solution proposals:

1. s/par-for-each/for-each/.  Will make compilation slower on multi-core
   machines.  We would do the same for guix pull, which is a bit sad
   because it's so fast right now.  Very simple solution though.

2. We find out some partitioning of the Scheme modules such that there
   is minimal overlap in total loaded modules when the modules in one
   subset are each loaded by one Guile process.  Then each Guile process
   loads & compiles the modules in its given subset serially, but these
   Guile processes run in parallel.  This could speed things up even
   more than now because the module-loading phases of the processes
   would be parallel too.  It also has the side-effect that less memory
   is consumed the fewer cores you have (because less Scheme modules
   loaded into memory at once).  If someone (Ludo?)  has a good general
   overview of Guix's module graph then maybe they can come up with a
   sensible partitioning of the modules, say into 4 subsets (maxing out
   benefits at quad-core), such that loading all modules in one subset
   loads a minimal amount of modules that are outside that subset.  That
   should be the only challenging part of this solution.

3. We do nothing for now since this bug triggers rarely, and can be
   worked around by simply re-running make.  (We just have to hope that
   it doesn't trigger on guix pull or on clean builds after some commit;
   there's no "just rerun make" in guix pull or an automated build of
   Guix.)  AFAIU Wingo expressed motivation to make Guile's module
   system thread safe, so this problem would then truly disappear.

I think #2 is a pretty good solution.  The only thing worrying me is
that we might not be able to sensibly partition the Scheme modules
according to any simple logic that can be automated (like guix/ is one
subset, gnu/packages/ is another, etc.).  Maintaining the subsets
manually in the Makefile would be pretty ugly.  But maybe some simple
logic, possibly combined with few special-cases in the code, would be
good enough.

Thoughts?

Taylan