[Python-Dev] "Fixing" the new GIL

David Beazley dave at dabeaz.com
Mon Mar 15 04:07:05 CET 2010

I have been following this discussion about fixing the GIL and just wanted to make a few comments about it.

To the doubters who don't think this is a real problem worth fixing, I must respectfully disagree.   Multicore systems and parallel programming issues are not 
going away any time in the foreseeable future.  Moreover, there are plenty of programmers who are using Python to build applications involving concurrency, 
distributed computing, and compute intensive processing.    While everyone agrees that it would be great if the GIL simply disappeared, the next best option is 
for the GIL to have well-defined and reasonably predictable behavior (i.e., behavior that can be easily explained and justified).   Specifically, if multiple threads 
happen to be performing CPU intensive work at the same time, it would be nice if they didn't thrash on multiple cores (the problem with the old GIL) and if I/O is 
mixed with CPU-bound processing it would be nice if I/O requests didn't have their responsiveness and priority penalized  (the problem with the new GIL).

So, just to be clear about the my bug report, it is directly related to the problem of overlapping I/O requests with CPU-bound processing.  This kind of scenario 
comes up in the context of many applications--especially those based on cooperating processes, multiprocessing, and message passing.  Ironically, these are 
exactly the kinds of parallel programming techniques that people are going to use because of the GIL in the first place.   So, why would you want the new GIL to 
behave poorly here?

In any case, if the GIL can be improved in a way that is simple and which either improves or doesn't negatively impact the performance of existing applications, 
why wouldn't you want to do it?  Seems like a no-brainer.


More information about the Python-Dev mailing list