[Python-Dev] Pythonic concurrency

Donovan Baarda abo at minkirri.apana.org.au
Mon Oct 10 17:01:05 CEST 2005

On Fri, 2005-10-07 at 17:47, Bruce Eckel wrote:
> Early in this thread there was a comment to the effect that "if you
> don't know how to use threads, don't use them," which I pointedly
> avoided responding to because it seemed to me to simply be
> inflammatory. But Ian Bicking just posted a weblog entry:
> http://blog.ianbicking.org/concurrency-and-processes.html where he
> says "threads aren't as hard as they imply" and "An especially poor
> argument is one that tells me that I'm currently being beaten with a
> stick, but apparently don't know it."

The problem with threads is at first glance they appear easy, which
seduces many beginning programmers into using them. The hard part is
knowing when and how to lock shared resources... at first glance you
don't even realise you need to do this. So many threaded applications
are broken and don't know it, because this kind of broken-ness is nearly
always intermittant and very hard to reproduce and debug.

One common alternative is async polling frameworks like Twisted. These
scare beginners away because a first glance, they appear hideously
complicated. However, if you take the time to get your head around them,
you get a better feel for all the nasty implications of concurrency, and
end up designing better applications.

This is the reason why, given a choice between an async and a threaded
implementation of an application, I will always choose the async
solution. Not because async is inherently better than threading, but
because the programmer who bothered to grock async is more likely to get
it right.

Donovan Baarda <abo at minkirri.apana.org.au>

More information about the Python-Dev mailing list