Re: bug: defining things in different threads

[Linas Vepstas]

The saga continues...

2008/11/20 Linas Vepstas <address@hidden>:
> 2008/11/15 Neil Jerram <address@hidden>:
>> 2008/11/12 Linas Vepstas <address@hidden>:
>>
>>> Yes, of course, the problem remains.
>>
>> Explanation:
>>
>> Thread 1 is the first thread that does any Guile stuff, so it loads
>> boot-9.scm, which means that it ends up in the (guile-user) module.
>>
>> Thread 2 hasn't done any (set-current-module ...), so it stays at the
>> default, which is (guile).
>>
>> Solution: add (define-module (guile-user)) to the code that you
>> execute in thread 2.
>
> This won't actually work, for some reason or another.
> Once I am in the second, third, etc. thread, then I cannot
> set the current module to be guile-user.  So, for example:
>
> scm-interp> (current-module)
> #<module (guile) f5e93e80>
> scm-interp> (define-module (guile-user))
> #<directory (guile-user) f5e96600>
> scm-interp>  (current-module)
> #<module (guile) f5e93e80>
> scm-interp> (set-current-module (define-module (guile-user)))
> #<directory (guile-user) f5e96600>
> scm-interp>  (current-module)
> #<module (guile) f5e93e80>
>
> Here, scm-interp is my shell, which just calls
> scm_c_eval() from C code.

This is because the C eval uses the dynwind to get into
a certain module.  So if one *sets* the module, the
dynwind mechanism promptly unsets it as one returns
after the evaluation.

--linas