Python time.sleep dauert viel länger

Question

Ich betreibe einen HTTP-Server (hausgemacht, in C++), der einen Python-Interpreter für Server-Side-Scripting einbettet. Dies ist ein Forking-Server, aber ich verwende kein Threading in einem übergeordneten Prozess. Ich mache keine seltsamen Dinge mit dem Python-Interpreter (außer den Gabeln).

In einem der Skripte, jedoch in einem anderen Thread, kann ein Anruf an time.sleep(0.1) bis zu einer Minute dauern, vor allem der erste Anruf.

while not self.should_stop(): 

    # other code 

    print "[PYTHON]: Sleeping" 
    time.sleep(0.1) 
    print "[PYTHON]: Slept, checking should_stop" 

Ich weiß, dass dies ist, wo es hängt, weil die Protokolle nur den ersten Druck zeigen, und der zweite viel, viel später.

Zusätzliche Informationen:

• die CPU nicht gebunden sind (~ 5%)
• dieses Python 2.7 auf Ubuntu
• Dies sind threading Fäden; Ich benutze Schlösser und Ereignisse wo nötig.
• Ich importiere keinen threading in irgendeinem Prozess, der jemals eine Verzweigung machen wird
• Python wird vor den Gabeln initialisiert; dies funktioniert anderswo groß (keine Probleme in den letzten 6 Monaten)

Answer 1

Python only onethreading.Thread zu einem Zeitpunkt ausgeführt werden kann, so dass, wenn es viele Threads sind, hat der Dolmetscher ständig zwischen ihnen wechseln zu, so ein Thread kann Führen Sie, während die anderen freezed oder mit anderen Worten unterbrochen werden.

Aber ein unterbrochener Faden wird nicht gesagt, dass es friert, es ist eine Art fällt bewusstlos für eine Weile und dann nach oben aufgeweckt und setzt ihre Arbeit fort, von wo aus es unterbrochen. Also, 0,5 Sekunden für einen bestimmten Thread kann tatsächlich im realen Leben länger sein.

Answer 2

Behoben!

Wie sich herausstellt, gibt der Hauptthread (der den C++ - Interpreter einbettet) die GIL nicht frei, wenn er nicht Python-Code ausführt (wie ich es mir vorgestellt habe). Sie müssen die GIL tatsächlich manuell freigeben, mit Py_BEGIN_ALLOW_THREADS und Py_END_ALLOW_THREADS, wie angegeben here.

Dadurch wird die Runtime-Version der GIL, so dass andere Threads während IO-intensiven Aufgaben ausgeführt werden können (wie in meinem Fall, Lesen oder Schreiben in/aus dem Netzwerk). Kein laufender Python-Code währenddessen.