This is the mail archive of the
mailing list for the Guile project.
Re: c++ -> guile threading
Keith Wright <email@example.com> writes:
> > From: Greg Harvey <Greg.Harvey@thezone.net>
> > I was thinking that the current
> > module would (and probably should) be local to the thread, but this is
> > not the case. Trying to figure out how to do it does make for a nice
> > little mind bending problem ;), but I think the only way you could do
> > this would be to make the various module variables into fluids, or
> > something similar.
> I was thinking that the current module would be entirely determined by
> the lexical context of the currently executing code, without regard to
> which thread might be executing that code. When I try to think about
> a current module determined at run-time when there is more than one
> thing running, my mind gets bent.
That's pretty much what I was thinking, though I didn't put it quite
right ;) The problem is that the module operations (define-module, for
example) operate on variables global to everyone, so if you do
(make-thread (lambda () (define-module (foo)) (display "bar"))),
the module of every thread becomes foo (though eval-in-module will
prevent that (oops ;)).