Während ich überprüfe, dass threading.Condition korrekt mit Affen gepatcht ist, habe ich festgestellt, dass sich ein monkeypatch threading.Thread(…).start() anders verhält als gevent.spawn(…) .
Überlegen Sie:
%Vor% Beachten Sie insbesondere die beiden Kommentare, die mit XXX beginnen.
Bei Verwendung der ersten Zeile (mit gevent.spawn ) löst der erste thread.join() eine Ausnahme aus:
Jedoch, Thread(…).start() (der zweite Block), alles funktioniert wie erwartet.
Warum sollte das sein? Was ist der Unterschied zwischen gevent.spawn() und Thread(…).start() ?
Was in Ihrem Code passiert, ist, dass die greenlets , die Sie in Ihrer threads -Liste erstellt haben, noch nicht ausgeführt werden konnten, weil gevent erst dann einen Kontextwechsel auslöst Sie tun dies explizit in Ihrem Code mit gevent.sleep() und so oder implizit durch Aufruf einer Funktion, die zB blockt semaphore.wait() oder by yielding und so weiter ..., um zu sehen, dass Sie einen Druck vor cv.wait() einfügen können und sehen, dass es erst aufgerufen wird, nachdem cv.notify_all() aufgerufen wurde:
Eine einfache Lösung für Ihren Code ist also, etwas einzufügen, das einen Kontextwechsel auslöst, nachdem Sie Ihre Liste mit greenlets erstellt haben, Beispiel:
%Vor% Hinweis: Ich bin immer noch neu bei gevent , also weiß ich nicht, ob dies der richtige Weg ist:)
Auf diese Weise haben alle greenlets die Möglichkeit, ausgeführt zu werden, und jede von ihnen löst einen Kontextwechsel aus, wenn sie cv.wait() aufrufen, und in der Zwischenzeit werden sie es tun
Registrieren Sie sich selbst bei den Condition Kellnern, so dass% code_% heißt
benachrichtigt alle greenlets .
HTH,
Tags und Links python multithreading gevent