Status of Python threading support (GIL removal)?

[Jure Erznožnik]

Sorry, just a few more thoughts:

Does anybody know why GIL can't be made more atomic? I mean, use
different locks for different parts of code?
This way there would be way less blocking and the plugin interface
could remain the same (the interpreter would know what lock it used
for the plugin, so the actual function for releasing / reacquiring the
lock could remain the same)
On second thought, forget this. This is probably exactly the cause of
free-threading reduced performance. Fine-graining the locks increased
the lock count and their implementation is rather slow per se. Strange
that *nix variants don't have InterlockedExchange, probably because
they aren't x86 specific. I find it strange that other architectures
wouldn't have these instructions though... Also, an OS should still be
able to support such a function even if underlying architecture
doesn't have it. After all, a kernel knows what it's currently running
and they are typically not preempted themselves.

Also, a beside question: why does python so like to use events instead
of "true" synchronization objects? Almost every library I looked at
used that. IMHO that's quite irrational. Using objects that are
intended for something else for the job while there are plenty of
"true" options supported in every OS out there.

Still, the free-threading mod could still work just fine if there was
just one more global variable added: current python thread count. A
simple check for value greater than 1 would trigger the
synchronization code, while having just one thread would introduce no
locking at all. Still, I didn't like the performance figures of the
mod (0.6 execution speed, pretty bad core / processor scaling)

I don't know why it's so hard to do simple locking just for writes to
globals. I used to do it massively and it always worked almost with no
penalty at all. It's true that those were all Windows programs, using
critical sections.