On Tue, 19 Sep 2017 19:04:21 +0800 Linas Vepstas <linasveps...@gmail.com> wrote: > On Fri, Sep 15, 2017 at 3:56 PM, Ludovic Courtès <l...@gnu.org> 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