Re: libguile thread safety

[Chris Vine <chris@cvine.freeserve.co.uk>]

On Sat, 04 Jan 2014 14:37:59 -0500
Mark H Weaver <mhw@netris.org> wrote:
> Indeed, top-level bindings are always looked up in the "current
> module". Each thread has its own "current module", but
> 'scm_with_guile' initially sets the current module to (guile-user).
> That's usually desirable, because you may have bound your own
> application-specific procedures and global variables in (guile-user),
> and you want all threads to have access to those by default.
> 
> The usual way to make thread-local variables in Guile is to use
> parameters[1] or fluids[2].  It's rather unusual to create fresh
> modules for each thread, but if you really want to do that you can
> start each thread by evaluating "(set-current-module
> (make-fresh-user-module))".
> 
> [1] API Reference > Scheduling > Parameters (section 6.21.8)
> [2] API Reference > Scheduling > Fluids and Dynamic States (section
> 6.21.7)

That's great.  Both using parameters and changing the current module to
one obtained by make-fresh-user-module works, but changing the current
module is the best fit for what I want to do with this.  Is it
efficiency concerns that make you think it unusual, or just that the
use case is unusual? (For anyone calling scm_c_eval_string() in a
multi-threaded program, as opposed to evaluating eval at the REPL, I
should have thought a fresh module was just what they wanted.)

make-fresh-user-module is not documented.  It might be worth adding it
to the documentation.

Chris