On Feb 26, 2010, at 4:27 AM, Jeffrey Yasskin wrote:
On Thu, Feb 25, 2010 at 1:33 AM, Brian Quinlan <br...@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
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
