[Python-Dev] New thread death in test_bsddb3

[Tim Peters]

[Martin v. L=F6wis]
> There are many good reasons; here is one scenario:
>
> Application A calls embedded Python. It creates thread state T1 to =
do
> so. Python calls library L1, which releases GIL. L1 calls L2. L2 ca=
lls
> back into Python. To do so, it allocates a new thread state, and
> acquires the GIL. All in one thread.
>
> L2 has no idea that A has already allocated a thread state for this
> thread. With the new API, L2 does not need any longer to create a t=
hread
> state. However, in older Python releases, this was necessary, so
> libraries do such things.

I understand that some people did this (we've bumped into two so far,
right?), but don't agree it was necessary:  the thrust of Mark's new =
code is
to make this easy to do in a uniform way, but people could (and did) =
build
their own layers of TLS-based Python wrappers before this (Mark is on=
e of
them; a former employer of mine is another).  AFAIK, though, these we=
re
cases where multiple libraries agreed to cooperate.  I don't really c=
are
anymore, since there's a standard way to do this now.

> It is unfortunate that these libraries now break, and I wish the ne=
w
> API would not be enforced so strictly yet.

If it were enforced in a release build I'd agree, but it isn't -- a r=
elease
build enforces nothing new here, and I want to be punched in the groi=
n when
a debug build spots dubious practice.

>> I already gave you my best guesses about those (no, yes).

> I think your guess is wrong: In the past, it was often *necessary* =
to
> have multiple thread states allocated for a single thread. There wa=
s
> simply no other option. So it can't be that this was not allowed.

It's a new world now -- let's get on with it.  Fighting for the right=
 to
retain lame code (judged by current stds, whether or not it was lame =
before)
isn't a cause I'll sign up for, and especially not when it's in an ex=
tremely
error-prone area of the C API, and certainly not when it's so easy to=
 repair
too.  But if you're determined to let slop slide in the debug build, =
check
in a change to stop the warning -- it's not important enough to me to=
 keep
arguing about it.  I don't think you'd be doing anyone a real favor, =
and
I'll leave it at that.