Questions about GIL and web services from a n00b

Ian hobson42 at
Sun Apr 17 17:15:22 CEST 2011

On 15/04/2011 20:17, Dan Stromberg wrote:
> On Fri, Apr 15, 2011 at 9:33 AM, Chris H
> <chris.humphres at>  wrote:
>> 1. Are you sure you want to use python because threading is not good due to
>> the Global Lock (GIL)?  Is this really an issue for multi-threaded web
>> services as seems to be indicated by the articles from a Google search?  If
>> not, how do you avoid this issue in a multi-threaded process to take
>> advantage of all the CPU cores available?
> Concurrency in Python is a largish topic.
> It's true that CPython's multithreading is poor.  In fact, running a
> multithreaded CPython application on n vs 2n cores can actually take
> more time on the 2n cores.
> However:
> 1) In Jython, and likely IronPython, threading is good.
The load times of Iron Python are ssslllooooowwwww!
(My tests showed startup times 4 to 6 times that of cpython on the same 
> 3) There's something called "stackless" and (similar to stackless)
> "greenlets".  While stackless allows you to use thousands of threads
> comfortably, it's still pretty single-core.  It's essentially a fork
> of CPython, and is being made a part of PyPy.  I believe greenlets are
> an attempt to bring what's good about stackless to CPython, in the
> form of a C extension module.
Greenlets are green threads - cooperative switching all in one system 
and therefore one core. Very lightweight.

> 4) I've heard that in CPython 3.2, the GIL is less troublesome, though
> I've not yet heard in what way.
Multiple threads still cannot run at the same time, however, if one 
thread runs too
long without a context switch, it relinquishes control and forces 
another thread to run.

This stops a low priority thread on one core, locking out a 
high-priority thread on
another. That this was happening is why 2 cores can be slower than one. 
(The overhead
of starting the second thread, finding it can't get the GIL and closing 
down again).

> 5) Even in CPython, I/O-bound processes are not slowed significantly
> by the GIL.  It's really CPU-bound processes that are.
Its ONLY when you have two or more CPU bound threads that you may have 



More information about the Python-list mailing list