decorators vs GIL

[Jeff Shannon]

Jarek Zgoda wrote:

>G. S. Hayes <sjdevnull at yahoo.com> pisze:
>
>  
>
>>>What really hurts is that I can't honestly tell Java programmers that
>>>      
>>>
>>>Python  is a slam dunk compared to Java & the JVM.  Java has no GIL,
>>>      
>>>
>>
>>Java has drunk the threads Kool-Aid, and Java programmers are very
>>likely to be thread-crazy because of the lack of a select equivalent
>>(until recently) and the lack of good access to processes via fork or
>>similar.  Luckily, it's usually pretty easy to convince people of the
>>benefits of NOT overusing threads once they've made that mistake once.
>>    
>>
>
>Try GUI programming without using threads.
>  
>

I've done this plenty of times.  Threads seem to only be essential when 
long-running background tasks are involved.  There's a large set of GUI 
programs where this is not an issue.  I've also never had GIL problems 
with multithreaded GUI apps.  Then again, I'm not writing for 
multiprocessor machines.

As I understand it, the GIL only becomes a real "problem" in the case of 
a multiprocessor machine running multithreaded code, and the "problem" 
is only that you get less-than-optimal efficiency.  I would submit that 
the vast majority of Python applications run on single-processor 
machines, and that for many of the apps that *are* run on SMP it's not 
essential to run at theoretical-optimum efficiency.  Multithreaded, 
multiprocessor applications where peak efficiency is necessary, threads 
can't be replaced by processes, and the use of C extensions (which don't 
suffer from GIL issues) is impractical make up a rather small section of 
the Python usage-base, and it's only those applications that see 
significant negative impacts from the GIL.  Yes, it'd be great if the 
GIL wasn't necessary, but if eliminating it makes *my* single-proc, 
single-thread apps run significantly slower then the change is a net loss.

Jeff Shannon
Technician/Programmer
Credit International