On Tue, Nov 1, 2011 at 1:31 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, Nov 1, 2011 at 6:01 PM, Stephen J. Turnbull <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>> wrote:<br>
>  > I've identified the problem I want to solve: I want to make<br>
>  > concurrent use of python objects "safe by default",<br>
><br>
> But that's not what you've proposed, AIUI.  You've proposed making<br>
> concurrent use *safer*, but not yet *safe*.  That's quite different<br>
> from the analogy with automatic memory management, where the<br>
> programmer can't do anything dangerous with pointers (because they<br>
> can't do anything at all).  The analogous model for concurrency is<br>
> processes, it seems to me.  (I don't have a desperate need for high-<br>
> performance concurrency, so I take no position on processes + message<br>
> passing vs. threads + shared resources.)<br>
<br>
Guido and python-dev in general *have* effectively taken a position on<br>
that, though (mainly due to Global Interpreter Lock discussions).<br>
<br>
1. Even for threads, the recommended approach is to use queue.Queue to<br>
avoid the common concurrency issues (such as race conditions and<br>
deadlock) associated with explicit locking<br>
2. In Python 3, concurrent.futures offers an even *safer* interface<br>
and higher level interface for many concurrent workloads<br>
3. If you use multiple processes and serialised messages, or higher<br>
level APIs like concurrent.futures, you can not only scale to multiple<br>
cores, but also to multiple *machines*.<br></blockquote><div><br></div><div>I am aware of all this. I've written large systems using Queue.queue and the multiple process/serialized messages model. I've dealt with code that tried to mix the two (*not* a good idea). The process model works really well - if you can use it. The problem is, if you can't, you lose all the protection it provides. That's the area I'm trying to address.</div>
<div><br></div><div>Also, the process model doesn't prevent these concurrency issues, it just moves them to external objects. I figure that's an even harder problem, since it can involve multiple machines. An improvement in the shared storage case might shed some light on it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This has led to a quite deserved reputation for being intolerant of<br>
changes that claim to make multithreaded development "better", but<br>
only at the expense of making single-threaded development worse.<br></blockquote><div><br></div><div>I think I've found a way to implement the proposal without having a serious impact on single-threaded code - at least in terms of performance and having to change the code.</div>
<div><br></div><div>     <mike</div><div><br></div></div>