decorators vs GIL

[Xavier Combelle]

Thank you for the address.this page is especially clear
I am quite agree with you.

Anthony Baxter wrote:

>On Sun, 08 Aug 2004 14:57:12 +0200, Xavier Combelle
><xavier.combelle at free.fr> wrote:
>  
>
>>For information is there some internet resources to understand what
>>exactly the GIL is about ?
>>    
>>
>
>Plenty - try this google search:
>http://www.google.com/search?q=site%3Adocs.python.org+GIL
>for a couple of simple ones, but there's plenty more - google for
>"python GIL" (or "python free-threading" for patches that were 
>written against Python 1.4 to remove the single lock. They ended
>up slowing down Python significantly.
>  
>
That is not really surprizing, the GIL is a very simple and very 
efficient way to manage
multithreading. After reading, I can't undersand that other interpreted 
languages don't do the same.
The use of GIL make that interpreter work as a single thread process.

>Note that much has been written about the GIL. Much of the stuff 
>I've seen has been from people who obviously don't understand
>it, but fear it anyway.
>
>  
>
Why fear it ? There is no really problems:  from a performance point of  
view, it's a very light way
to limit the overhead of  mutltithreading.. From developper point of 
view, it seems to be just
a constraint to write C code which access to Python. Moreover, just 
blocking IO, or code
wich do a lot of computing seems to worry about it.  For blocking IO, I 
wonder, if  the main part
si not used by the development team of python and for long computing 
task, a different heavy
process seems be better design. I am certainly wrong, but I don't see where.

>Anthony
>  
>