[stdlib-sig] futures - a new package for asynchronous execution

[Brian Quinlan]

On Feb 26, 2010, at 4:27 AM, Jeffrey Yasskin wrote:
> On Thu, Feb 25, 2010 at 1:33 AM, Brian Quinlan <brian at sweetapp.com>  
> wrote:
> Your process pool still relies on future._condition, but I think you  
> can just delete that line and everything will still work. This seems  
> fine to me. Thanks!

Oops. Fixed. Thanks.

> Heh. If you're going to put that in the pep, at least make it  
> correct (sleeping is not synchronization):

I can't tell if you are joking or not. Was my demonstration of a  
possible deadlock scenario really unclear?

> import threading
> condition = threading.Condition(threading.Lock())
> a = None
> b = None
>
> def wait_on_b():
>   with condition:
>     while b is None:
>       condition.wait()
>   print(b.result())
>   return 5
>
> def wait_on_a():
>   with condition:
>     while a is None:
>       condition.wait()
>   print(a.result())
>   return 6
>
> f = ThreadPoolExecutor(max_workers=2)
> with condition:
>   a = f.submit(wait_on_b)
>   b = f.submit(wait_on_a)
>   condition.notifyAll()
>
> In any case, I've updated the docs and PEP to indicate that  
> deadlocks are possible.
>
> Thanks. I still disagree, and think users are much more likely to be  
> surprised by occasional deadlocks due to cycles of executors than  
> they are about guaranteed deadlocks from cycles of futures, but I  
> don't want to be the only one holding up the PEP by insisting on this.

Cycles of futures are not guaranteed to deadlock. Remove the sleeps  
from my example and it will deadlock a small percentage of the time.

Cheers,
Brian

> I think there are places the names could be improved, and Jesse  
> probably has an opinion on exactly where this should go in the  
> package hierarchy, but I think it will make a good addition to the  
> standard library. Thanks for working on it!
>
> Jeffrey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20100226/f1452639/attachment.html>