Re: [Python-de] threads

25/09/2012 - 13:52 von Diez Roggisch | Report spam
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
 

Lesen sie die antworten

#1 wg
25/09/2012 - 17:49 | Warnen spam
On 25.09.2012 13:52, Diez Roggisch wrote:
On 9/25/12 1:08 PM, "wg" 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

Ähnliche fragen