[stdlib-sig] futures - a new package for asynchronous execution
jyasskin at gmail.com
Fri Feb 26 04:26:17 CET 2010
On Thu, Feb 25, 2010 at 7:10 PM, Brian Quinlan <brian at sweetapp.com> wrote:
> On Feb 26, 2010, at 4:27 AM, Jeffrey Yasskin wrote:
>> 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?
It's clear; it's just wrong code, even if the futures weren't a cycle.
Waiting using sleep in any decently-sized system is guaranteed to
cause problems. Yes, this example will work nearly every time
(although if you get your load high enough, you'll still see
NameErrors), but it's not the kind of thing we should be showing
users. (For that matter, communicating between futures using globals
is also a bad use of them, but it's not outright broken.)
>> 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.
It only fails to deadlock when it fails to create a cycle of futures.
It sounds like Antoine also wants you to either have the threaded
futures steal work or detect executor cycles and raise an exception.
More information about the stdlib-sig