On 25.09.2012 11:08, Diez Roggisch wrote:
On 9/25/12 9:34 AM, "wg" <wg1@gmx.net> wrote:
On 24.09.2012 22:08, Vinzent Hoefler wrote:
wg wrote:
gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2 aktiv wird?
Mit einem entsprechenden Lock, ja.
Vinzent.
OK, dazu muss ich thread 2 über lock oder queue steuern. Da ich aber thread 2 an *beliebiger* Stelle von *thread 1* aus anhalten will, kommt ich das so nicht machen.
Beliebig gibt's nicht. Wenn der Thread im C-Callstack steht, wird der ausgeführt.
Gibt's eine Möglichkeit, den GIL (von python aus) zu beeinflussen? Und zwar in der Form, daß thread 1 den GIL-State für sich beansprucht. Das C-API hat so eine Funktion: PyGILState_STATE PyGILState_Ensure()
Nichts offizielles, das ist bestenfalls ein hack. Du kannst natürlich versuchen, über ctypes an's GIL zu kommen.
Hast dafür evtl. Hinweise/Links wie sowas gehen könnte?
Und muss diese Salami-Taktik bei der Problembeschreibung sein? Das beständige Glaskugelwetzen ist anstrengendŠ
Diez
Ja, hast recht (Glaskugel?wetzen?); 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. Wird wohl ein C-framework dafür notwendig sein. Wolf
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. -- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
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. Wolf
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
Am 25.09.2012 13:52, schrieb Diez Roggisch:
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.
Diez hat absolut recht. Das gewünschte Verhalten ist mit threads nicht umsetzbar. Wenn du einen Programmablauf zu jeder Zeit, sofort und zuverlässig beenden willst, dann musst du einen weiteren Prozess verwenden. Nicht mal pthread_cancel() oder pthread_kill() garantieren ein verlässliches und zeitnahes beenden eines Threads. Mal abgesehen davon, dass bei pthread_kill() dein Programm in einem undefinierten Zustand hängen wird. Dein Problem ist unabhängig von Python und ist auch mit reinem C-Code nicht umsetzbar. Selbst bei Prozessen geht es mit SIGTERM, SIGKILL, SIGSTOP / SIGCONT nicht zuverlässig synchron. Christian
wg wrote:
Das ist eine realtime Videoüberwachung und der workerthread 2 führt Aktionen durch, die u.U. vom GUI aus *sofort* angehalten werden sollen.
Sofort ist relativ. Facts for fun: Bei üblicher Nervenleitgeschwindigkeit vergehen inklusive der Muskelbewegung und taktilem Feedback auch bei Schnellklickern locker 30 ms, bis die gesamte Signalstrecke Großhirn -> Zeigefinger -> Großhirn überwunden ist. Anders gesagt hat der Rechner schon ca. 20 ms Zeit, bevor der User überhaupt selbst merkt, daß er tatsächlich geklickt hat. 20 ms allerdings sind auf halbwegs modernen Rechnern mittlerweile so was wie eine Ewigkeit, selbst mit interpretierten Sprachen.
Der thread 2 ist tief verschachtelt, eine Abfrage 'kann i weitermachen' müsste an vielen Stellen eingebaut werden.
Nein, nur in der inneren Schleife. ;) Vinzent. -- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
participants (4)
-
Christian Heimes -
Diez Roggisch -
Vinzent Hoefler -
wg