On 25.09.2012 13:52, Diez Roggisch wrote:
On 9/25/12 1:08 PM, "wg" wg1@gmx.net wrote:
On 25.09.2012 12:23, Vinzent Hoefler wrote:
wg wrote:
ich wolle nur niemanden mit folgender Aufgabenstellung langweilen: Thread 1 mit GUI, Daten werden von thread 2 via queue geliefert. Thread 1 kann mit Button (oder Key) thread 2 *an belibeiger* Stelle pausieren lassen.
Jetzt muß ich doch mal blöd fragen: Wozu? Wenn die Queue voll ist, wird Thread 2 doch ohnehin angehalten, weil er nix mehr schreiben kann. Damit wäre es von Thread 1 aus am einfachsten, die Queue nicht mehr auszulesen, um Thread 2 schlafen zu legen.
Notfalls kann man auch an der Queue-Semantik ein wenig rumschrauben und dort etwas wie "jetzt keine Nachrichten mehr akzeptieren, auch wenn Queue noch nicht voll ist" implementieren.
Vinzent.
Das ist eine realtime Videoüberwachung und der workerthread 2 führt Aktionen durch, die u.U. vom GUI aus *sofort* angehalten werden sollen. Der thread 2 ist tief verschachtelt, eine Abfrage 'kann i weitermachen' müsste an vielen Stellen eingebaut werden.
Angehalten oder abgebrochen? Wenn letzteres, dann vielleicht doch besser über das Modul multiprocessing gehen + einfach den Subprozess töten.
Und in Antwort auf deine andere Mail: nein, ich habe da keinen Beispielcode, und ich zweifele auch ein bisschen an der Durchführbarkeit.
Eine Garantie für dieses Verhalten kann es letztlich auch mit dem GIL nicht geben, denn wie gesagt - wenn du dich da in einem C-Callstack befindest, dann hat das GIL da keinen Einfluss mehr.
Da ist Prozess töten wirklich die bessere Alternative.
Diez
thread stop/run ist gefordert, auf Interpreterlevel. Eine Variante mit python: win32process.SuspendThread(thread) win32process.ResumeThread(thread) Nur daß so unter bestimmten Umständen das GUI hängenbleibt.
Daher ist eine C/Python-Anwendung wahrscheinlich der beste Weg. Oder aber man nehme anstelle von threads Prozesse, wie du vorschlägst.
Danke für deine Kommentare, Wolf