Extension modules, Threading, and the GIL

[Martin v. Löwis]

bokr at oz.net (Bengt Richter) writes:

> PyEval_AcquireThread(tstate) requires a tstate to swap in when
> acquiring the lock, AFAICS, and a raw OS thread would not have a
> tstate unless it built one. I was trying to suggest that there might
> be a thread in Dave's universe that doesn't have a tstate built, and
> therefore can't properly acquire the lock. That's why I was musing
> on the possibility of an OS thread automatically having a tstate
> built for it if it didn't have one.

This is unlikely. tstate isn't a global variable, so if you invoke
AcquireThread, you have to create a thread state yourself first. This
is independent of whether the thread was created with
start_new_thread: When you are in a position to invoke AcquireThread,
you *never* have a thread state you could use, you always have to
create one (unless you can come up with some clever machinery, such as
storing the thread state in TLS). People using AcquireThread usually
know this.

Of course, without inspecting the actual source, this is all
speculation.

Regards,
Martin