killing thread ?

[Laura Creighton]

> 
> >
> > The thread object itself could have the flag, so you don't need to
> > have a global "hit list" of threads with the added overhead of
> > checking the GIL.  
> 
> Everything seems fine except that if I'm thread A and I want to tell thread
> B to jump off a cliff, I need to communicate that to thread B somehow, and as
>  
> far as I can tell, there's no way for thread A to do this unless I change 
> thread.start_new to return some object with a pointer to the thread's t_state
>  
> context. To make matters even worse, the t_state struct that is used in the 
> interpretter loop is created by the new thread itself, and not the function 
> that actually makes the OS call to create the thread. So currently, there is 
> no way for me to get my hands on the t_state without some semi-non-trivial 
> change. I guess if I wanted to, I could pass a pointer to some object that 
> could be changed by the newly created thread, use locks to protect the 
> information inside that object, and hope that by the time I'm ready to kill 
> thread B, thread B has already written a pointer to it's t_state structure. 
> Or I could use a global dictionary, to get my hands on the t_state.... 
> 
> Anton
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

Use a queue to communicate between threads.  Pass a message
that says 'go die'.  You may need 2 queues, if you need to
get messages back as well.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965