killing thread ?
anton.wilson at camotion.com
Tue Feb 11 22:07:19 CET 2003
> 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....
More information about the Python-list