2008/11/19 Neil Jerram <[EMAIL PROTECTED]>: > 2008/11/15 Linas Vepstas <[EMAIL PROTECTED]>: >> >> 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
