Hi Valery,
On Tue, Dec 8, 2009 at 2:56 PM, Valery Khamenya <
kham...@gmail.com> wrote:
> Hi Collin,
>
>>
>> That's correct. We don't have any plans to improve this situation
>> during Q4. Because of the sensitive nature of GIL-related work, we'd
>> like to do that in mainline CPython (rather than Unladen Swallow) to
>> avoid introducing subtle bugs during merger.
>
> 2.6-2.7 will not address this for sure.
> It's a pity.
Correct. Our work would be done in the 3.x branch.
> More sadly is something like this:
>
http://www.grouplens.org/node/244
> Finally, the Python itself has no evident requirement in such a
> counter-productive thing. It is about implementation, not about languaguage
> specification. If the reference Python's implementation is in some way too
> conservative -- that's understood. But then, I guess, some advanced
> implementation should address such challenges.
> Who if not Unladen Swallow?..
Say what you will about the GIL (and I've plenty to say), but it
*does* simplify CPython's internals, and that's no small thing when
CPython is maintained by an all-volunteer workforce.
Removing the GIL also seriously hurts the performance of individual
threads. One of the goals of Unladen Swallow is to increase the
performance of individual threads to the point where GIL removal might
be possible without a net loss of performance.
Unladen Swallow is constrained by a) the existing CPython codebase,
and b) not-unlimited engineering time. The benefits of removing the
GIL are long-term, in that it chiefly enables applications that have
not yet been written (or rewritten). Jython has no GIL, nor does
IronPython IIRC. If you need GIL-less Python *today*, I'd recommend
you use one of those implementations.
Thanks,
Collin Winter