-
Notifications
You must be signed in to change notification settings - Fork 937
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Group().imap on Queue deadlock #423
Comments
A Go version (using imap_unordered instead of imap): http://play.golang.org/p/TGKE5Kh1u0 , which works fine. |
Will anyone tell me if this is intended, or a bug of gevent? Thanks in advance! |
@thinxer This seems to be a bug in IMap: def _run(self):
try:
empty = True
func = self.func
for item in self.iterable:
self.count += 1
g = self.spawn(func, item)
....
def _on_result(self, greenlet):
self.count -= 1
if greenlet.successful():
self.queue.put((greenlet.index, greenlet.value))
else:
self.queue.put((greenlet.index, Failure(greenlet.exception)))
if self.ready() and self.count <= 0:
self.maxindex += 1
self.queue.put((self.maxindex, Failure(StopIteration)))
def _on_finish(self, _self):
if not self.successful():
self.maxindex += 1
self.queue.put((self.maxindex, Failure(self.exception))) This piece of code assumes that |
Yes it is. One of my coworkers pointed out the same issue. Checking |
@thinxer I think it should be okay - even replacing the current |
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer.
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer (close #424). Fix #311: same issue.
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer (close #424). Fix #311: same issue.
fix #423: pool: LoopExit in imap/imap_unordered
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer (close #424). Fix #311: same issue.
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer (close #424). Fix #311: same issue.
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer (close #424). Fix #311: same issue.
It was possible for IMap/IMapUnordered greenlets to exit without putting the final StopIteration. So, whoever was waiting on the results would have to wait forever (or until LoopExit if there's nothing else running in the program). Original patch and test by @thinxer (close #424). Fix #311: same issue.
Output:
It seems that
imap
never stopped, thoughfetches
been putStopIteration
.Update:
Using Python 2.7 on Mac OS X Mavericks.
gevent.version is "1.0".
The text was updated successfully, but these errors were encountered: