<br><br><div class="gmail_quote">On 4 November 2011 09:41, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Fri, Nov 4, 2011 at 5:03 PM, Adam Jorgensen<br>
<<a href="mailto:adam.jorgensen.za@gmail.com">adam.jorgensen.za@gmail.com</a>> wrote:<br>
> The GIL makes them pseudo-pointless in CPython anyway and the headaches<br>
> arising from<br>
> threading are very frustrating.<br>
<br>
</div>This is just plain false. Threads are still an excellent way to take a<br>
synchronous operation and make it asynchronous. Take a look at<br>
concurrent.futures in 3.2, which makes it trivial to take independent<br>
blocking tasks and run them in parallel. The *only* time the GIL<br>
causes problems is when you have CPU bound threads written in pure<br>
Python. That's only a fraction of all of the Python apps out there,<br>
many of which are either calling out to calculations in C or FORTRAN<br>
(scientific community, financial community) or else performing IO<br>
bound tasks (most everyone else with a network connection).<br></blockquote><div><br></div><div>I would love to seem some actual stats on this? How many multi-threaded</div><div>apps are hitting the GIL barrier, etc...</div>

<div><br></div><div>Anyway, I consider myself refuted...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
People need to remember that *concurrency is a hard problem*. That's<br>
why we layer abstractions on top of it. The threading and<br>
multiprocessing modules are both fairly low level, so they offer lots<br>
of ways to shoot yourself in the foot, but also a lot of power and<br>
flexibility.<br>
<br>
The concurrent.futures model is a higher level abstraction that's much<br>
easier to get right.<br>
<div class="im"><br>
> Personally I would rather see an Actors library...<br>
<br>
</div>And what is an actors library going to use as its concurrency<br>
mechanism if the threading and multiprocessing modules aren't there<br>
under the hood?<br></blockquote><div><br></div><div>I said nothing about removing the multi-processing module, although it</div><div>would be nice if it spawned child processes didn't randomly zombify</div><div>for no good reason.</div>

<div><br></div><div>Regardless, I still think the GIL should be fixed or the threading module</div><div>removed. It's disingenuous to have a threading module when it doesn't work</div><div>as advertised due to an interpreter "feature" of dubious merit anyway.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888">Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span></blockquote></div><br>