Message210709
I'm looking into a solution for this. The idea is pretty straightforward: http://codereview.appspot.com/61210043.
This needs more code to support the optional timeout feature, and it now returns Futures instead of coroutines (which I think is fine).
But to my surprise, test_as_completed_reverse_wait() failed. After nearly an hour of debugging my own code I realized that this test specifically verifies the following weird behavior: if you get two values (futures/coroutines) out of as_completed() without waiting for either, and then wait for the *second* one, it will wait for the *first* result. I guess this is defensible because it is the first one you wait for, but I find it hard to believe that this is desirable behavior -- even though I wrote the code and the test! (http://code.google.com/p/tulip/source/detail?r=674355412f33.)
So I'd like permission to just change these semantics. They aren't clear from the docs or from PEP 3156, and concurrent.futures.as_completed() doesn't have the same issue (there, __next__() on the iterator blocks until the result is ready). |
|
Date |
User |
Action |
Args |
2014-02-09 01:17:24 | gvanrossum | set | recipients:
+ gvanrossum, pitrou, vstinner, yselivanov, glangford |
2014-02-09 01:17:23 | gvanrossum | set | messageid: <1391908643.29.0.569488321764.issue20566@psf.upfronthosting.co.za> |
2014-02-09 01:17:23 | gvanrossum | link | issue20566 messages |
2014-02-09 01:17:19 | gvanrossum | create | |
|