guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug: defining things in different threads


From: Linas Vepstas
Subject: Re: bug: defining things in different threads
Date: Thu, 20 Nov 2008 12:21:42 -0600

2008/11/19 Neil Jerram <address@hidden>:
> 2008/11/15 Linas Vepstas <address@hidden>:
>>
>> Well, originally, my code loaded a smob interface
>> (defined a bunch of smobs)  in thread 1, which I then
>> found to be undefined in thread 2 (and all subsequent
>> threads).  Would your fix solve this?
>
> I guess yes if the problem was trying to reference the definitions
> from the wrong module; no if the problem was define not being
> threadsafe.  (And I'm guessing it was the latter.)

No, the former:  as you point out in the previous email, the
first thread to run is in the (guile-user) module. Typically,
the first thread is where application-defined smobs would
be set up and initialized.   At some point, additional threads
are created, and go into guile mode.  None of these threads
perform an explicit  (set-current-module (guile-user)), and
so the application smobs are undefined in those threads.

Thus, it would seem that symbols defined at the "global
scope" of the first thread aren't perceived as global in the
others.

The problem can be thought of in two ways:
A) the guile docs do not mention that new threads should
perform a (set-current-module ...) and so app developers
won't ... and will discover this behaviour as a surprise.

B) I think documenting this is "wrong"; it puts un-necessary
additional burden on the app developer (it can be non trivial
to  perform all the required initializations in exactly the right
places).  Rather, the semantics that I want to have happen
is that something defined (at global scope) in one thread
should be visible in all threads.

>> Under the "principle of least surprise", I certainly was
>> surprised that not all threads behaved the same; I got
>> bitten by this, and wasted a day debugging this, and
>> designing a  work-around for this "feature".
>
> Do you mean you think fluids should not exist, or that
> (current-module) should not be a fluid?

No.

I don't understand why the (guile-user) module of the first
thread is scoped differently than the (guile) module of all
of the other threads. I think that what I want is for all
threads default to the same module on startup.

> (On the other hand, if you mean just that define should be threadsafe,
> I definitely agree with that!)

Well, yes.

--linas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]