killing thread ?

[anton wilson]

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