Panicz Maciej Godek <[email protected]> writes:
> 2014/1/4 Chris Vine <[email protected]>:
>> 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
