killing thread ?

[Peter Hansen]

anton wilson wrote:
> 
> > 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....

Ah... I've always followed the advice to stick to the threading.Thread
class instead of anything in the thread.py module, and more than that
I've always done threads by _subclassing_ that class, rather than passing
in my target function as a reference... as such, my relatively narrow
experience with threads in Python leads me to feel this is simpler than 
it probably is.  :-(

-Peter