Win32 WMI Process Monitoring

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Win32 WMI Process Monitoring

Beitragvon droptix » Sonntag 10. Februar 2008, 04:00

Ich bastel mir grad einen Process Monitor für Windows, der u.a. neue Prozesse erkennt. Er basiert auf den Win32 Extensions und WMI Event-Watcher. Unten folgt der Code-Snippet…

Problem: Lasse ich die Funktion test() durchlaufen, klappt alles (nach einem Timeout von 10 Sekunden wird diese beendet). Nun habe ich das ganze aufgebohrt und möchte nicht nur neue Prozesse erkennen. Ich bekomme folgende seltsame Fehlermeldung (für jeden der 4 Threads ein Fehler) und die CPU-Auslastung steigt auf 100%.

Findet jemand nen Fehler? Liegt's vielleicht am Threading?

Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Programme\Python24\lib\threading.py", line 442, in __bootstrap
self.run()
File "C:\Programme\Python24\lib\threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "procmon.py", line 53, in __run_watcher
process = watcher()
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 1015, in __call__
handle_com_error (error_info)
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 187, in handle_com
_error
exception_string.append (" %s - %s" % (hex (scode), error_description.strip
()))
AttributeError: 'NoneType' object has no attribute 'strip'

Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Programme\Python24\lib\threading.py", line 442, in __bootstrap
self.run()
File "C:\Programme\Python24\lib\threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "procmon.py", line 53, in __run_watcher
process = watcher()
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 1015, in __call__
handle_com_error (error_info)
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 187, in handle_com
_error
exception_string.append (" %s - %s" % (hex (scode), error_description.strip
()))
AttributeError: 'NoneType' object has no attribute 'strip'

Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Programme\Python24\lib\threading.py", line 442, in __bootstrap
self.run()
File "C:\Programme\Python24\lib\threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "procmon.py", line 53, in __run_watcher
process = watcher()
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 1015, in __call__
handle_com_error (error_info)
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 187, in handle_com
_error
exception_string.append (" %s - %s" % (hex (scode), error_description.strip
()))
AttributeError: 'NoneType' object has no attribute 'strip'

Exception in thread Thread-3:
Traceback (most recent call last):
File "C:\Programme\Python24\lib\threading.py", line 442, in __bootstrap
self.run()
File "C:\Programme\Python24\lib\threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "procmon.py", line 53, in __run_watcher
process = watcher()
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 1015, in __call__
handle_com_error (error_info)
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 187, in handle_com
_error
exception_string.append (" %s - %s" % (hex (scode), error_description.strip
()))
AttributeError: 'NoneType' object has no attribute 'strip'


Manchmal kommt aber auch die Fehlermeldung hier:

Traceback (most recent call last):
File "procmon.py", line 10, in ?
class Win32ProcessMonitor:
File "procmon.py", line 11, in Win32ProcessMonitor
__wmi = wmi.WMI()
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 1124, in connect
handle_com_error (error_info)
File "C:\Programme\Python24\Lib\site-packages\wmi.py", line 188, in handle_com
_error
raise x_wmi, "\n".join (exception_string)
wmi.x_wmi: -0x7ffdfff7 - Ausnahmefehler aufgetreten.
Error in: SWbemServicesEx
-0x7ffbef94 - Datentrõgerkontingentverletzung


Hier der Code:

Code von Gerold ausgelagert: http://paste.pocoo.org/show/26860/

Tags: Win32 WMI Prozess Monitor Process Monitor

Edit by Gerold: Code ausgelagert
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Re: Win32 WMI Process Monitoring

Beitragvon gerold » Sonntag 10. Februar 2008, 08:49

droptix hat geschrieben:

Code: Alles auswählen

      while self.__running:
         try:
            pass
         except KeyboardInterrupt:
            self.stop()

Hallo droptix!

Die oben gezeigte Codestelle dürfte der Grund für die totale Auslastung des Prozessors sein.

Weiters glaube ich, dass du es mit den doppelten Unterstrichen ("__") maßlos übertreibst. Vor wem willst du denn den Code schützen?

Du greifst auch von mehreren Threads aus (zumindest glaube ich das so verstanden zu haben) auf das WMI-Objekt zu. Das ist nicht gut. COM-Objekte solltest du nicht threadübergreifend vewenden.

Du verwendest das highlevel-Modul "threading", nutzt es aber nicht zur Vereinfachung der Struktur. Ich persönlich würde Threading in Klasseninstanzen kapseln. Je eine "__init__"-, "run"-, und "stop"-Methode um den Thread steuerbar zu machen.

Du verwendest Klassenvariablen (__wmi, __running, __watchers). Klassenvariablen sind keine Instanzvariablen und werden von **allen Instanzen geteilt** -- also genau das Gegenteil von dem, was man meistens mit Klasseninstanzen erreichen will.

Weiters würde ich Callback-Funktionen (und vielleicht andere Abläufe, die mir beim Drüberlesen nicht aufgefallen sind) mit Locks absichern.

Alles in Allem empfehle ich dir, beim Threading eine schön gekapselte Struktur mit Klasseninstanzen zu etablieren, denn gerade beim Threading kann viel zu viel schief gehen. Da ist es nicht günstig, wenn man keinen Überblick darüber behält, wo überhaupt einzelne Threads am Arbeiten sind. Jeder neue Thread bekommt eine eigene Klasseninstanz (threading.Thread) -- und fertig.


Code ausgelagert: http://paste.pocoo.org/show/26861/


Ich will dich damit sicher nicht ärgern. Es tut mir leid, dass ich dein Programm so zerrissen habe. :roll:

mfg
Gerold
:-)
Zuletzt geändert von gerold am Sonntag 10. Februar 2008, 13:01, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Re: Win32 WMI Process Monitoring

Beitragvon droptix » Sonntag 10. Februar 2008, 11:35

gerold hat geschrieben:Ich will dich damit sicher nicht ärgern. Es tut mir leid, dass ich dein Programm so zerrissen habe.


Kein Problem, das bringt mich doch ein Stück weiter :)

gerold hat geschrieben:
droptix hat geschrieben:

Code: Alles auswählen

      while self.__running:
         try:
            pass
         except KeyboardInterrupt:
            self.stop()

Hallo droptix!

Die oben gezeigte Codestelle dürfte der Grund für die totale Auslastung des Prozessors sein.


Einerseits logisch, weil Endlosschleife. Andererseits gibt's dort nichts zu tun. Wie könnte ich denn elegant einen "Listener" auf KeyboardInterrupt setzen, so dass mein Programm bei Ctrl+C stoppt? Die `start()`-Methode in die try-Anweisung packen?

gerold hat geschrieben:Weiters glaube ich, dass du es mit den doppelten Unterstrichen ("__") maßlos übertreibst. Vor wem willst du denn den Code schützen?


Vor niemandem, aber ich erkenne daran sofort welche Variablen und Methoden von außen zugänglich sind und welche nur intern benutzt werden. Ist das irgendwie schädlich oder nur dein persönlicher Eindruck?

gerold hat geschrieben:Du greifst auch von mehreren Threads aus (zumindest glaube ich das so verstanden zu haben) auf das WMI-Objekt zu. Das ist nicht gut. COM-Objekte solltest du nicht threadübergreifend vewenden.


Weil? Es werden in `__init__()` 4 Watcher-Objekte mittels WMI erstellt. In den Threads wird dann auf diese Objekte zugegriffen, aber es werden zur Laufzeit keine neuen WMI-Instanzen erzeugt. Kann mir nicht vorstellen, wie ich es anders lösen sollte.

gerold hat geschrieben:Du verwendest das highlevel-Modul "threading", nutzt es aber nicht zur Vereinfachung der Struktur. Ich persönlich würde Threading in Klasseninstanzen kapseln. Je eine "__init__"-, "run"-, und "stop"-Methode um den Thread steuerbar zu machen.


Kling gut, werde mich an deinem Code-Snippet orientieren. Gefällt mir sehr… ich bin neu bei Threads :)

gerold hat geschrieben:Du verwendest Klassenvariablen (__wmi, __running, __watchers). Klassenvariablen sind keine Instanzvariablen und werden von **allen Instanzen geteilt** -- also genau das Gegenteil von dem, was man meistens mit Klasseninstanzen erreichen will.


Verstehe nicht ganz. Das sind Eigenschaften der Klasse, die in jeder Instanz gleich sein sollen. So war das angedacht… verstehe grad nicht was dort schlecht dran ist. Auch die `__watchers`-Liste wird für jede Instanz gleich befüllt.

gerold hat geschrieben:Weiters würde ich Callback-Funktionen (und vielleicht andere Abläufe, die mir beim Drüberlesen nicht aufgefallen sind) mit Locks absichern.


Wenn ich das richtig verstanden habe braucht man das nur dort, wo Threads auf gleiche Objekte gleichzeitig zugreifen. Da Python nicht wirklich Multicore-Threading macht, werden Threads schließlich doch alle sequenziell ausgeführt, oder? Bei mir wird später eine Datenbank eine Rolle spielen, aber da kann ich doch "parallel" von jedem Thread drauf zugreifen, oder?
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Sonntag 10. Februar 2008, 12:23

So, habe ein paar deiner Ratschläge beherzigt. Entspricht das so etwa deinen Vorstellungen?

P.S. Die Fehler sind immer noch da :( Das Dumme ist, ich weiß nicht was sie bedeuten.


Code ausgelagert: http://paste.pocoo.org/show/26862/


Edit by Gerold: Code ausgelagert
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Re: Win32 WMI Process Monitoring

Beitragvon Leonidas » Sonntag 10. Februar 2008, 12:30

droptix hat geschrieben:
gerold hat geschrieben:Weiters glaube ich, dass du es mit den doppelten Unterstrichen ("__") maßlos übertreibst. Vor wem willst du denn den Code schützen?


Vor niemandem, aber ich erkenne daran sofort welche Variablen und Methoden von außen zugänglich sind und welche nur intern benutzt werden. Ist das irgendwie schädlich oder nur dein persönlicher Eindruck?

Schädlich nicht, aber wohl der persönliche Eindruck der meisten Regulars hier, mich eingeschlossen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Re: Win32 WMI Process Monitoring

Beitragvon gerold » Sonntag 10. Februar 2008, 12:39

droptix hat geschrieben:Wie könnte ich denn elegant einen "Listener" auf KeyboardInterrupt setzen, so dass mein Programm bei Ctrl+C stoppt? Die `start()`-Methode in die try-Anweisung packen?

Das hilft nichts. Aber Zeile 71 (sleep) kannst du in try-except einschließen. Das sollte funktionieren.


droptix hat geschrieben:ich erkenne daran sofort welche Variablen und Methoden von außen zugänglich sind und welche nur intern benutzt werden. Ist das irgendwie schädlich oder nur dein persönlicher Eindruck?

Dafür würde ein Unterstrich auch genügen. Zwei Unterstriche heißt: "Finger weg! Auch wenn du glaubst, zu wissen was du tust!"


droptix hat geschrieben:
gerold hat geschrieben:COM-Objekte solltest du nicht threadübergreifend vewenden.

Weil?

Weil COM nicht threadsicher ist und schon öfter hier im Forum Probleme, die in diesem Zusammenhang stehen, so gelöst wurden, indem COM nicht threadübergreifend verwendet wurde.
Ich weiß nicht welches wmi-Modul du importierst, aber ich kann mir nicht vorstellen, dass es ein Problem sein wird, ``wmi.WMI()`` mehrfach zu instanzieren. Aber ich habe es auch nicht ausprobiert -- weil ich nicht weiß was du dafür verwendet hast.


droptix hat geschrieben:
gerold hat geschrieben:mit Locks absichern.

Wenn ich das richtig verstanden habe braucht man das nur dort, wo Threads auf gleiche Objekte gleichzeitig zugreifen. Da Python nicht wirklich Multicore-Threading macht, werden Threads schließlich doch alle sequenziell ausgeführt, oder?

So wie ich das verstanden habe, kümmert sich GIL darum, dass eine Python-Anweisung -- also so etwas wie ``print "Hallo"``, ``a = 10`` oder ``for i in range(10)`` unterbrochen wird. Das bedeutet aber nicht, dass zwischen ZWEI Anweisungen nicht etwas Anderes erledigt wird.

Du kannst dich beim Threading also nicht darauf verlassen, dass in folgendem Beispiel die Variable "x" auf den Wert 10 zeigt.

Code: Alles auswählen

x = 10
print x

Das sind zwei Anweisungen. Zwischen ``x = 10`` und ``print x`` könnte ein anderer Thread die Variable ``x`` geändert haben.

Das kannst du verhindern, indem du vorher einen Lock setzt. Einen Lock, den alle Threads benutzen müssen, bevor sie diesen Codeteil ausführen.

Vorsicht!!! Eine Funktion ist nicht nur eine Python-Anweisung. Eine Funktion besteht aus mehreren Anweisungen.

Code: Alles auswählen

x = 20

def hallo():
    global x
    x = 10
    print x

hallo()

Auch wenn der Funktionsaufruf ``hallo()`` nur eine Befehlszeile ist. Es schützt dich nicht vor Änderungen eines anderen Threads, wenn du in der Funktion auf **nicht-lokale** Objekte zugreifst.

Also immer dann, wenn du von einem Thread aus etwas änderst, was auch von anderen Threads aus geändert werden könnte (also Objekte die du mit anderen Threads teilst), dann musst du dich darum kümmern, dass dir kein anderer Thread reinpfuschen kann.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Sonntag 10. Februar 2008, 13:09

Hallo droptix!

Ich weiß leider noch nicht was das Programm eigentlich tun soll. Gibt es dafür auch ein funktionierendes Beispiel ohne Threading? Vielleicht kann ich dann nachvollziehen, wo die Fehler liegen.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Sonntag 10. Februar 2008, 13:39

Hallo droptix!

Das hier hat mich auf die Spur gebracht: http://www.python-forum.de/topic-5427.html

Ich habe dieses WMI-Modul dafür verwendet: http://tgolden.sc.sabren.com/python/wmi.html

Dieses Beispiel funktioniert bei mir:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-15 -*-

import wmi
import threading
import pythoncom
import time


class WatcherThread(threading.Thread):
   
    def __init__(self, notification_type):
        threading.Thread.__init__(self)
        self._stop_event = threading.Event()
        self.notification_type = notification_type
   
   
    def run(self):
       
        pythoncom.CoInitialize()
        try:
            c = wmi.WMI()
            watcher = c.Win32_Process.watch_for(
                notification_type = self.notification_type
            )
           
            while True:
                if self._stop_event.isSet():
                    break
                try:
                    process = watcher(timeout_ms = 1000)
                    self.callback(process)
                except wmi.x_wmi_timed_out:
                    pass
        finally:
            try:
                pythoncom.CoUninitialize()
            except:
                pass
   
   
    def callback(self, process):
        """
        Diese Funktion kann überschrieben werden
        """
       
        print process.Caption
   
   
    def stop(self):
        self._stop_event.set()


def main():
    creation_watch = WatcherThread("creation")
    creation_watch.start()
    try:
        time.sleep(10)
    except KeyboardInterrupt:
        pass
    finally:
        creation_watch.stop()
        creation_watch.join()


if __name__ == "__main__":
    main()

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Montag 11. Februar 2008, 11:45

Na was das Tool machen soll ist einfach: live an den Windows Event-Handler horchen und reagieren, wenn neue Prozesse erstellt/gekillt werden. Dafür benutze ich ebenfalls Tim Golden's WMI Modul (gibt's denn noch andere?).

Mit einem älteren Tool gehe ich einen anderen Weg: ich lese jede Sekunde per WMI die Prozessliste aus und vergleiche sie mit der Liste von davor. Ich ermittle also neu hinzugekommene und nicht mehr vorhandene Prozesse. Das Problem: das Sekunden-Polling erzeugt CPU-Last von 3% bis 7% (wahrscheinlich je nach CPU-Leistung) und ist zudem ungenau. Es kann also sein dass mir Prozesse durch die Lappen gehen, die kürzer als eine Sekunde "leben". Daher soll mein neues Tool in Echtzeit an den Windows Event-Handler horchen.

Das mit Threads und Locks hatte ich also richtig verstanden: braucht man nur, wenn die Threads auf gleiche Objekte zugreifen. Aber in den meisten Fällen kann man das sicher nicht 100%-ig ausschließen, v.a. dann nicht wenn man eine Callback-Funktion zum Überschreiben freigibt und nicht weiß, was der Benutzer damit machen wird. Also würde ich das später noch mit Locks absichern.

Dein Beispiel-Code macht Dinge, hinter die ich erst durchsteigen muss (pythoncom.CoInitialize()). Eins sehe ich aber sofort: Auch du hast ein zwischenzeitliches Timeout von einer Sekunde drin. D.h. auch hier könnten mir kurzlebige Prozesse durch die Lappen gehen, richtig? Genau das möchte ich verhindern.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Montag 11. Februar 2008, 12:27

droptix hat geschrieben:Dein Beispiel-Code macht Dinge, hinter die ich erst durchsteigen muss (pythoncom.CoInitialize()). Eins sehe ich aber sofort: Auch du hast ein zwischenzeitliches Timeout von einer Sekunde drin. D.h. auch hier könnten mir kurzlebige Prozesse durch die Lappen gehen, richtig? Genau das möchte ich verhindern.

Hallo droptix!

``CoInitialize`` wird in der "pywin32-Hilfe" und in der "Windows Platform SDK" beschrieben. Es initialisiert COM für einen Thread. Ohne diesen Befehl kannst du kein COM-Objekt in einem Thread benutzen. Und damit das auch wirklich läuft, musst du dich in jedem Fall auch darum kümmern, dass ``CoUninitialize`` aufgerufen wird. Deshalb steht das im ``finally``-Zweig.

Die Zeile

Code: Alles auswählen

process = watcher(timeout_ms = 1000)

gibt an, dass der Watcher eine Sekunde lang horchen soll. Ist diese Sekunde abgelaufen, wird der Watcher beendet. Das passiert aber in einer Schleife, so dass der Watcher nur wenige Millisekunden (oder gar Mikrosekunden) nicht aktiv ist.

Die Unterbrechung ist wichtig, ansonsten würde der Watcher den Thread komplett blockieren und ließe sich nicht einfach beenden. Vielleicht durch eine KeyboardInterrupt -- aber das habe ich nicht ausprobiert. Du kannst das Timeout auf 3000 ms erhöhen. Damit ist es schon fast ausgeschlossen, dass dir ein Prozess durch die Lappen geht. Drei Sekunden ist für einen Computer eine halbe Ewigkeit. Je höher das Timeout ist, desto geringer die Wahrscheinlichkeit, dass dir genau zum Zeitpunkt des Timeouts ein neuer Prozess durch die Lappen geht.

Das bedeutet aber auch, dass das Beenden der Threads bis zu drei Sekunden dauern kann.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Dienstag 12. Februar 2008, 09:01

OK, klingt schonmal gut. Trotzdem wäre es möglich, dass ein Prozess zwischen dem Beenden des Watchers und des Neustartens erzeugt wird und ich davon nichts mitkriege? Auch wenn der Zeitpunkt nur ultrakurz und die Wahrscheinlichkeit gering ist -> möglich wäre es also. Das ist zwar besser als mein 1-Sekunden-Polling, aber nicht exakt.

Und das Timeout ist nur drin, um den Thread beenden zu können, richtig? Wird der Thread nicht beendet, wenn ich das Programm beende? Sonst würde ich gern auf diese Pause verzichten wollen, damit mir kein Prozess durch die Lappen geht.

Trotzdem bleibt folgendes Problem: Ein neuer Prozess wird gestartet. Der Watcher wird beendet mit einem Process-Objekt als Returnwert. Nun muss mein Python-Code das erstmal verarbeiten (mit der Callback-Funktion). Erst danach loopt die while-Schleife erneut und der Watcher horcht wieder. Während die Callback-Funktion durchläuft könnten auch weitere Prozesse gestartet werden und ich kriege davon nichts mit. Das ist die zweite Schwachstelle.

Noch zwei Ideen/Fragen dazu:

1) Ich habe mal gehört, dass man irgendwie eine Callback-Funktion an einen Event-Handler des Betriebssystems schicken kann, so dass das Betriebssystem zuerst diese Callback-Funktion ausführt, bevor der Prozess weiter läuft. Dann würde sich das Betriebssystem darum kümmern und wirklich jeden Prozess berücksichtigen.

2) Kann ich mit Python einen Prozess in den Pause-Zustand versetzen, also einfrieren und wieder aufwecken? Dann hätte ich mehr Zeit, die Callback-Funktion auszuführen.

Danke!
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Dienstag 12. Februar 2008, 09:26

Hallo droptix!

Wenn Leben davon abhängen, dass dir kein Prozess durch die Finger rutscht, dann musst du dich direkt an Microsoft wenden. Aber wenn Leben davon abhängen, dann möchte ich mich nicht auf Microsoft verlassen müssen. :wink:

Du kannst die Rückkehr von deinem Callback beschleunigen, indem du den Callback in einen neuen Thread verlagerst.

Ob der Watcher schön beendet wird, wenn dein Programm beendet wird, kannst du ja ausprobieren. Dann kannst du auf den Timeout verzichten. Und auf die stop-Methode und auf den _stop_event. Und auf das ``join()`` am Ende des Programms.

Dann gibt es noch ``threading.Threas.setDaemon`` mit dem du dich spielen kannst.

mfg
Gerold
:-)

PS: Das Übergeben von eigenen Callback-Funktionen als Eventhandler, kenn ich nur von Programmen aber nicht in Verbindung mit der Prozessüberwachung. Aber vielleicht findest du ja etwas im Microsoft Windows Platform SDK zu diesem Thema.
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Dienstag 12. Februar 2008, 11:41

gerold hat geschrieben:Wenn Leben davon abhängen, dass dir kein Prozess durch die Finger rutscht, dann musst du dich direkt an Microsoft wenden. Aber wenn Leben davon abhängen, dann möchte ich mich nicht auf Microsoft verlassen müssen. :wink:


Wer will das schon :P

gerold hat geschrieben:Du kannst die Rückkehr von deinem Callback beschleunigen, indem du den Callback in einen neuen Thread verlagerst.


Daran hab ich auch schon gedacht, aber dann bleibt eigentlich immer noch das Problem, dass mir was durch die Lappen geht, während ich die Callback als Thread starte… irgendwo ist immer eine Lücke. Ich möchte versuchen die zu schließen, damit ich sagen kann: mein Tool arbeitet "zuverlässig" :)

gerold hat geschrieben:Dann gibt es noch ``threading.Threas.setDaemon`` mit dem du dich spielen kannst.


Ich schau mal, was da geht… Danke!

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder