Status of Python threading support (GIL removal)?

[Lie Ryan]

Jure Erznožnik wrote:
> On Jun 20, 1:36 am, a... at pythoncraft.com (Aahz) wrote:
>> You should put up or shut up -- I've certainly seen multi-core speedup
>> with threaded software, so show us your benchmarks!
>> --
> 
> Sorry, no intent to offend anyone here. Flame wars are not my thing.
> 
> I have shown my benchmarks. See first post and click on the link.
> That's the reason I started this discussion.
> 
> All I'm saying is that you can get threading benefit, but only if the
> threading in question is implemented in C plugin.
> I have yet to see pure Python code which does take advantage of
> multiple cores. From what I read about GIL, this is simply impossible
> by design.
> 
> But I'm not disputing the fact that cPython as a whole can take
> advantage of multiple cores. There certainly are built-in objects that
> work as they should.

I never used threading together with I/O intensively before, but I heard
that I/O operations releases the GIL, and such they're similar to
GIL-releasing C extensions which makes it possible to benefit from
multicore in I/O bound pure python code.

Perhaps we should have more built-in/stdlib operations that can release
GIL safely to release GIL by default? And perhaps some builtin/stdlib
should receive an optional argument that instruct them to release GIL
and by passing this argument, you're making a contract that you wouldn't
do certain things that would disturb the builtin/stdlib's operations;
the specifics of what operations are prohibited would be noted on their
docs.