[Python-3000] threading, part 2

Guido van Rossum guido at python.org
Wed Aug 9 22:39:25 CEST 2006

On 8/9/06, Tim Peters <tim.peters at gmail.com> wrote:
> [Nick Coghlan]
> >> That check is already there:
> >>
> >> int PyThreadState_SetAsyncExc(  long id, PyObject *exc)
> >>      Asynchronously raise an exception in a thread. The id argument is the
> >> thread id of the target thread; exc is the exception object to be raised. This
> >> function does not steal any references to exc. To prevent naive misuse, you
> >> must write your own C extension to call this. Must be called with the GIL
> >> held. Returns the number of thread states modified; if it returns a number
> >> greater than one, you're in trouble, and you should call it again with exc set
> >> to NULL to revert the effect. This raises no exceptions. New in version 2.3.
> Guido, do you have any idea now what the "number greater than one"
> business is about?  That would happen if and only if we found more
> than one thread state with the given thread id in the interpreter's
> list of thread states, but we're counting those with both the GIL and
> the global head_mutex lock held.  My impression has been that it would
> be an internal logic error if we ever saw this count exceed 1.

Right, I think that's it. I guess I was in a grumpy mood when I wrote
this (and Just & Alex never ended up using it!).

> While I'm at it, I expect:
>                 Py_CLEAR(p->async_exc);
>                 Py_XINCREF(exc);
>                 p->async_exc = exc;
> is better written:
>                 Py_XINCREF(exc);
>                 Py_CLEAR(p->async_exc);
>                 p->async_exc = exc;
> for the same reason one should always incref B before decrefing A in
>     A = B
> ...

That reason that A and B might already be the same object, right?

> >> All Tober is really asking for is a method on threading.Thread objects that
> >> uses this existing API to set a builtin ThreadExit exception. The thread
> >> module would consider a thread finishing with ThreadExit to be
> >> non-exceptional, so you could easily do:
> >>
> >>    th.terminate() # Raise ThreadExit in th's thread of control
> >>    th.join() # Should finish up pretty quickly
> >>
> >> Proper resource cleanup would be reliant on correct use of try/finally or with
> >> statements, but that's the case regardless of whether or not asynchronous
> >> exceptions are allowed.
> [Guido]
> > I'm +0 on this.
> Me too, although it won't stay that simple, and I'm clear as mud on
> how implementations other than CPython could implement this.

Another good reason to keep it accessible from the C API only. Now I'm
-0 on adding it. I suggest that if someone really wants this
accessible from Python, they should research how Jython, IronPython,
PyPy and Stackless could handle this, and report their research in a

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list