stupid thread question

Michael Vanier mvanier at endor.bbb.caltech.edu
Wed Jun 14 21:41:55 EDT 2000


gmcm at hypernet.com (Gordon McMillan) writes:

> [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

Right you are; sorry.  Here is the code that doesn't work:

#! /usr/bin/env python

import os, sys, string, thread
from Tkinter import *


def run():
    i = 0

    while 1:
        print "in child thread"
        if stop_flag:
            print "leaving child thread"
            break


#
# Main body of program.
#

# Globals.

tkgeometry        = "200x200+0+0"      # Default; can be overridden.
start_time        = 0.075
root = Tk()
root.geometry(tkgeometry)
stop_flag = 0
thread_on = 0

def callback(event):
    global thread_on
    key = event.char

    if key == "s":
        if not thread_on:
            stop_flag = 0
            thread_on = 1
            thread.start_new_thread(run, ())
        else:
            print "halting thread"
            stop_flag = 1
            thread_on = 0
    elif key == "q":
        raise SystemExit


frame = Frame(root, width=200, height=200)
frame.bind_all("<Key>", callback)
frame.pack()
os.system("sleep 2")
root.mainloop()

# End of script.

To test it, hit "s" in the Tk window to start and again to (attempt to)
stop.  It won't work, but if stop_flag is a list with an integer element and
the code is suitably modified, it will.  Also, without the Tkinter code, it
does work.

Sorry-to-belabor-the-point-ly y'rs,

Mike


--------------------------------------------------------------
Mike Vanier	mvanier at bbb.caltech.edu
Department of Computation and Neural Systems, Caltech 216-76
GNU/Linux: We can't lose; we're on a mission from God.



More information about the Python-list mailing list