stupid thread question

[Gordon McMillan]

[posted and mailed]

Michael Vanier wrote: 

>gmcm at hypernet.com (Gordon McMillan) writes:
>
>> Michael Vanier: 

[snip]

>> >To fix this, I changed the flag to be a list with one integer
>> >element. Now, when I change the list element in the parent, the child
>> >sees it too.  
>> 
>> 
>> Let me guess. You did something like make "flag" a module level
>> global, and then did "from ... import *" in the other.
>
>Even dumber than this; it was all in the same file.  I set the global in
>the parent thread, and expected that the new thread would see the new
>value when it was changed.

And did the routine that set it say "global flag"? If not, it set a local 
(within the routine).

>> 
>> If you had referenced "module.flag", all would have worked. But that 
>> stinks, too. Your thread should have a flag member, and the parent
>> thread should set it (through a setter, if you really want to be
>> virtuous <wink>). That way the flag becomes part of the thread's API,
>> instead of a bass- ackwards dependency.
>> 
>
>Well, the thread wasn't an object; I just called a function and expected
>that it would see the same data (see below).

Ah. I assumed that you were using threading, not thread. The latter is the 
low level primitives. The former is the one to use.

>So what you're saying is that a thread's namespace is not the same as
>the global namespace of the parent.  This is puzzling, since that's what
>I thought a thread was: effectively a new process which shares the
>parent's namespace.  Is this in a FAQ somewhere?  Or am I just not
>getting it? 

No you're not. This has NOTHING to do with threads.

>To further complicate things, here is a stripped-down version of the
>code that actually works!

If you'd post the code that *doesn't* work, then we could quit this 
guessing game!


5-to-1-on-the-missing-global-ly y'rs

- Gordon