[Python-3000] threading, part 2

[Guido van Rossum]

On 8/9/06, Tim Peters <tim.peters at gmail.com> wrote:
> [back and forth on PyThreadState_SetAsyncExc()]
>
> [Tim]
> >> Guido, do you have any idea now what the "number greater than one"
> >> business is about?
> >> ...
> >> My impression has been that it would be an internal logic error if we
> >> ever saw this count exceed 1.
>
> [Guido]
> > Right, I think that's it. I guess I was in a grumpy mood when I wrote
> > this
>
> I forgot that we talked about this close to two years ago:
>
>     http://www.python.org/sf/1069160
>
> As comments there say, it's still the case that it's clearly possible
> to provoke this into deadlocking (but unlikely if you're not
> deliberately trying to).
>
> > (and Just & Alex never ended up using it!).
>
> They spoke for themselves on this matter in that bug report ;-)
>
> >> 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?
>
> Right, or that B's only owned reference is on a chain only reachable
> from A, and in either case A's incoming refcount is 1.  The suggested
> deadlock-avoiding rewrite in the patch comment addresses that too.

So why didn't we check that in?

> ...
>
> >>> I'm +0 on [exposing] this [from Python].
>
> >> 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
> > PEP.
>
> As a full-blown language feature, I'm -1 unless that work is done
> first.  I'm still +0 on adding it to CPython if it's given a
> leading-underscore name and docs to make clear that it's a
> CPython-specific hack that may never work under any other
> implementation.

Fine with me then. In 2.5? 2.6? Or py3k? (This is the py3k list.)

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