Re: Guile bugs

[Chris Vine]

On Tue, 19 Sep 2017 19:04:21 +0800
Linas Vepstas <address@hidden> wrote:
> On Fri, Sep 15, 2017 at 3:56 PM, Ludovic Courtès <address@hidden> wrote:
[snip]
> > That said, if you run a REPL server in a separate thread and mutate
> > the global state of the program, you could possibly crash it—no
> > wonders here.
> >  
> 
> Yes, well, I would call that a bug! It feels like you are trying to
> blame me for a guile bug -- its not my fault that it crashes!
> 
> I did not look very carefully, and don't recall what the stack traces
> looked like, but I got the impression that there were race conditions
> in guile init, and how it interacted with the sockets.

Your problems are clearly at least partly at a deeper level, and you
may already know what I say below on thread safety, but:

(i) you cannot auto-compile the same file concurrently in two different
threads, for obvious reasons: the generated 'go' file will be a mash up
to two different compilations.  I have not had a problem with
user-compiling files concurrently to different locations, although I
accept that you may have (although you say this is rare).

(ii) prior to guile-2.0.10, guile initialization was not thread safe -
you needed to have entered scm_with_guile() at least once in a single
thread, and completed initialization (say by having scm_with_guile()
return), before starting any new threads which might invoke
scm_with_guile() or evaluate any scheme expressions.

(iii) modifying most system non-fluid/non-parameter globals is thread
unsafe.  In particular, loading modules concurrently for the first time
will lead to problems (you have to load all required modules up front
in a single thread before starting any new threads which might
independently try to load the modules).  Ports are also not thread safe
(rightly so in my view), and I believe that extends to the global stdout
and stdin ports.

Chris