[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libguile thread safety
From: |
Chris Vine |
Subject: |
Re: libguile thread safety |
Date: |
Sat, 4 Jan 2014 21:01:18 +0000 |
On Sat, 04 Jan 2014 14:37:59 -0500
Mark H Weaver <address@hidden> 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
- Re: libguile thread safety, (continued)
Re: libguile thread safety, Mark H Weaver, 2014/01/03
- Re: libguile thread safety, Chris Vine, 2014/01/04
- Re: libguile thread safety, Chris Vine, 2014/01/04
- Re: libguile thread safety, Panicz Maciej Godek, 2014/01/04
- Re: libguile thread safety, Chris Vine, 2014/01/04
- Re: libguile thread safety, Mark H Weaver, 2014/01/04
- Re: libguile thread safety,
Chris Vine <=
- Re: libguile thread safety, Panicz Maciej Godek, 2014/01/04
- Re: libguile thread safety, Chris Vine, 2014/01/04
- Re: libguile thread safety, Panicz Maciej Godek, 2014/01/05
- Re: libguile thread safety, Mark H Weaver, 2014/01/05
Re: libguile thread safety, Ludovic Courtès, 2014/01/04