[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libguile thread safety
From: |
Mark H Weaver |
Subject: |
Re: libguile thread safety |
Date: |
Sat, 04 Jan 2014 14:37:59 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Panicz Maciej Godek <address@hidden> writes:
> 2014/1/4 Chris Vine <address@hidden>:
>> It seems as if top level variables in code evaluated by scm_c_eval_string()
>> are shared between concurrently running threads. Is this really the
>> intended behaviour (it is a significant and unexpected usability
>> restriction)? Maciej (I hope that is your first name) can you reproduce
>> this?
>
[...]
>
> It indeed does seem that the threads share their top-level bindings on
> guile's side, and I suppose that this is the intended behaviour. I
> think that it can be easily adjusted with scm_eval_string_in_module,
> i.e. if you provide a separate module for each thread.
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)
Mark
- 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 <=
- 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, 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