On Sat, 04 Jan 2014 14:37:59 -0500 Mark H Weaver <m...@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
