<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7233.28">
<TITLE>RE: [Python-Dev] Pythonic concurrency</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Steve Holden wrote:<BR>
> The nice thing about Python threads (or rather threading.threads) is<BR>
> that since each thread is an instance it's *relatively* easy to ensure<BR>
> that a thread restricts itself to manipulating thread-local resources<BR>
> (i.e. instance members).<BR>
><BR>
> This makes it possible to write algorithms parameterized for the number<BR>
> of "worker threads" where the workers are taking their tasks off a Queue<BR>
> with entries generated by a single producer thread. With care, multiple<BR>
> producers can be used. More complex inter-thread communications are<BR>
> problematic, and arbitrary access to foreign-thread state is a nightmare<BR>
> (although the position has been somewhat alleviated by the introduction<BR>
> of threading.local).<BR>
<BR>
"Somewhat alleviated" and somewhat worsened. I've had half a dozen conversations in the last year about sharing data between threads; in every case, I've had to work quite hard to convince the other person that threading.local is *not* magic pixie thread dust. Each time, they had come to the conclusion that if they had a global variable, they could just stick a reference to it into a threading.local object and instantly have safe, concurrent access to it.<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>
</BODY>
</HTML>