Child Prozesse andocken?

  • Moin,


    und zwar möchte ich mit der Hauptdatei (Parent Prozess) mehrere Child Prozesse starten (multi processing). Jedoch haben die Prozesse kein GUI.

    Ich wollte eigentlich _WinAPI_SetParent() benutzen, aber dafür benötigt man ja GUI's. Und ein "unsichtbares" GUI erstellen ist auch nicht so das Wahre.

    Mit dem AutoIt Gui (AutoItWinGetTitle) funktioniert das auch nicht so, wie ich mir das vorgestellt habe. Die Fenster kann man nicht zu 100% sicher identifizieren.


    Wenn ich nun den Taskmanager öffne (win10), sind die Prozesse wild in der Prozessliste verteilt. Es wäre aber viel besser, wenn die Child Prozesse am Parent Prozess

    andocken würden. :huh:


    Gibt es da eine Möglichkeit? Ich habe mir die WinAPIProc.au3 mal angeschaut, aber nichts gefunden. :rolleyes:


    So wie hier beim Windows Explorer: (Bild von Google)
    [IMG:https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2017/01/task-manager-processes-part.jpg?itok=EcrjtvVD]



    Viele Grüße,

    xSunLighTx3

  • Kommen diese "Child-Prozesse" nicht eigentlich nur zustande, wenn Multithreading betrieben wird? - Bei AutoIt dürfte das glaube ich so einfach nicht funktionieren, wenn es wirklich nur daran geht die Prozesse im Taskmanager untereinander anzuzeigen.

  • Kann sein, ich habe Multithreading noch gar nicht so genutzt. Beim ISN Studio ist mir auch aufgefallen, dass der externe Helper Prozess an dem Hauptprozess "gebunden" ist.

    Der Source des Projektes ist zwar öffentlich, aber ich habe es nach langem Ausprobieren nicht geschafft, da durchzusteigen. :(


    Naja, vielleicht probiere ich überhaupt erstmal, inwiefern ich ein simples Multi Processing mit AutoIt hinkriege. Ich habe auch vor, das Ergebnis zu veröffentlichen.

    Für bestimmte Anwendungszwecke ist das ja eigentlich ganz sinnvoll. :)


    Auf jeden Fall vielen Dank für deine Antwort!

  • Multiprocessing ist super easy. Einfach childs als Konsolenversion compilieren und in der Hauptdatei dann nutzen (fileinstall() in @temp und von dort starten, nachher artig aufräumen).

  • Multiprocessing ist super easy. Einfach childs als Konsolenversion compilieren und in der Hauptdatei dann nutzen (fileinstall() in @temp und von dort starten, nachher artig aufräumen).


    Wow, das klappt ja perfekt. Danke dir, Zec!

    Dann werde ich mich mal die nächsten Tage daransetzen. :)

  • Ja, ist der Hammer, nutze das inzwischen wenn immer möglich. Also z.B. alles, was etwas läuft und man nicht unbedingt zeitkritisch eine Erfolg/Misserfolgmeldung braucht. Ist zwar kein Mutlithreading, nutzt aber wenigstens mehrere Kerne / Hyperthreading.

  • Bei AutoIt gibt es für was alles ein workaround, aber dennoch hat man viele Einschränkungen. Multithreading wäre eine sehr wirkungsvolle Funktion gewesen.


    Aber mal sehen, inwiefern man mit mehreren Prozessen wirkungsvoll arbeiten kann. :)


    Ein Problem, welches ich jetzt schon erahne, ist das Einfrieren von Child Prozessen.

    Es kann ja auch vorkommen, dass andere Anwendungen den Prozessor auslasten, sodass

    einige Prozesse dann gar nicht mehr anständig verabreitet werden und somit das Hauptskript keine

    zeitgemäße Antwort mehr vom Child Prozess bekommt. ;(


    Das Austauschen von Informationen zwischen den Prozessen ist auch wieder so eine Sache, die nicht

    zwingend reibungslos und zuverlässig ablaufen muss.

  • Hallo xSunLighTx3  

    Das Austauschen von Informationen zwischen den Prozessen ist auch wieder so eine Sache, die nicht

    zwingend reibungslos und zuverlässig ablaufen muss.

    Wenn du die GUI benutzbar halten willst, bieten sich die _Timer_*** - Funktionen an. (Also nicht mit RunWait oder einer Schleife auf Statusmeldungen warten, sondern mit einer über Timer gestarteten Funktion abfragen). So kannst du dein Fenster jederzeit bedienbar erhalten (und gut Multithreading simulieren).

  • Ja, ist richtig. Zum child ist problemlos über mehrere Wege möglich, aber zurück und einigermaßen schnell... Naja. AutoIt ist nunmal eine Skriptsprache. :S

    Ich werde auf jeden Fall einige Sachen ausprobieren und dann mein bestes Ergebnis posten. Aber ich bin nicht der beste, das muss ich noch anmerken. :D


    Hallo xSunLighTx3  

    Wenn du die GUI benutzbar halten willst, bieten sich die _Timer_*** - Funktionen an. (Also nicht mit RunWait oder einer Schleife auf Statusmeldungen warten, sondern mit einer über Timer gestarteten Funktion abfragen). So kannst du dein Fenster jederzeit bedienbar erhalten (und gut Multithreading simulieren).

    Stimmt, mit Timern habe ich auch schon viel gearbeitet. Ich hatte leider öfters Probleme bei schwächeren PC's. Wenn du große Schleifen hast, die viel Zeit benötigen und

    zwischendurch immer die Timer ins Spiel kommen, kann sich das Skript schnell mal selbst aufhängen. Und die Timer schieben immer neue Aufgabe in die Que. :(


    Ich habe mir schon ein paar Abläufe überlegt und werde mal schauen, was am besten funktionieren wird. 8)

  • Oh, wir reden hier aneinander vorbei.

    Ich ging von deinem genannten Szenario mit weiteren gestarteten Prozessen aus und ich meine auch nicht AdlibRegister.

    Ich habe mir schon ein paar Abläufe überlegt und werde mal schauen, was am besten funktionieren wird.

    Gut. Ich bin der Meinung, wenn du dir vor der Umsetzung Gedanken machst, wie du eine Oberfläche immer bedienbar hältst, dann kriegst du das auch mit AutoIt hin.

  • Ich arbeite gerade an einem ähnlichen Problem (will div. berechnungen in CHild Prozessen ausführen lassen, damit ich mehrere Prozessorkerne verwenden kann).


    Habe mirüberlegt das mit Named Pipes zu machen, funktioniert das so oder sehe ich das falsch?

  • Jaja, gerade bei Multiprocessing ist es sau schade, dass Windows die Funktionen exec und fork zusammenfasst... Ein einfaches fork wäre hier schon cool!


    Kommunikation geht auch sehr gut über TCP. Das hat den Vorteil, dass das Programm mit wenig Änderungen auch auf mehreren Rechnern (Stichwort "Verteilte Systeme") laufen kann.

  • Bin ich auch gerade bei. Hier eine UDF und ein Beispiel für hin und her. Ich weiß nicht mehr, wo ich sie gefunden habe, Ist jedenfalls nicht von mir. :saint:

    UDF

    Zum Testen am besten beide Apps compilieren.

  • Moin Zec,


    die UDF ist eigentlich ganz nice.

    Ich habe sie auch mal im autoitscript Forum gesehen, wenn mich nicht alles täuscht. :D


    So ähnlich wollte ich das auch gestalten. Vielleicht kann man ja auf der UDF aufbauen.


    Danke nochmals fürs Posten. :)