killing thread ?
Laura Creighton
lac at strakt.com
Tue Feb 11 18:31:51 EST 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....
>
> 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
More information about the Python-list
mailing list