Durante il doppio controllo che la patch di threading.Condition
sia corretta per la scimmia, ho notato che un threading.Thread(…).start()
monkeypatched si comporta in modo diverso da gevent.spawn(…)
.Perché `gevent.spawn` è diverso da un` threading.Thread() `monkeypatched?
considerare:
from gevent import monkey; monkey.patch_all()
from threading import Thread, Condition
import gevent
cv = Condition()
def wait_on_cv(x):
cv.acquire()
cv.wait()
print "Here:", x
cv.release()
# XXX: This code yields "This operation would block forever" when joining the first thread
threads = [ gevent.spawn(wait_on_cv, x) for x in range(10) ]
"""
# XXX: This code, which seems semantically similar, works correctly
threads = [ Thread(target=wait_on_cv, args=(x,)) for x in range(10) ]
for t in threads:
t.start()
"""
cv.acquire()
cv.notify_all()
print "Notified!"
cv.release()
for x, thread in enumerate(threads):
print "Joining", x
thread.join()
nota, in particolare, i due commenti che iniziano con XXX
.
Quando si utilizza la prima linea (con gevent.spawn
), il primo thread.join()
solleva un'eccezione:
Notified! Joining 0 Traceback (most recent call last): File "foo.py", line 30, in thread.join() File "…/gevent/greenlet.py", line 291, in join result = self.parent.switch() File "…/gevent/hub.py", line 381, in switch return greenlet.switch(self) gevent.hub.LoopExit: This operation would block forever
Tuttavia, Thread(…).start()
(il secondo blocco), tutto funziona come previsto.
Perché dovrebbe essere? Qual è la differenza tra gevent.spawn()
e Thread(…).start()
?