Verwendung einer beliebigen Anzahl von Parametern für den Aufruf einer Funktion

  • Hallo Zusammen,

    ich bin seit einiger Zeit nach einer sauberen Lösung für mein Problem. Ich baue mir aktuell diverse Wiederverwendbare Module u.a. arbeite ich an mehreren Klassen zum Thema Multithreading. Dabei bin ich auf gewisse "Probleme" gestoßen. U.a. Aufruf verschiedener Funktionen etc... also bin ich auf die Idee gekommen die Module queue und functools zu verwenden. Ich bin auch zu einer funktionierenden aktuell aber unschönen und vor allem unflexiblen Lösung gekommen. Vor allem die Rückgabe der "fertigen" Jobs ist zwar wie bereits in meinem Szenario funktional mehr aber auch nicht. Daher erhoffe ich mir einen kleinen Denkanstoß.

    Jobklasse:

    Das Problem besteht in der Methode getJob(). Hier bin ich doch eben sehr unflexibel. Die Klasse wird mit den verschiedensten Funktionen aufgerufen, wobei verschiedene Parameter verwendet werden.
    Beispiel für einen Aufruf:

    Allerdings könnte es auch sein, dass der Aufrufparameter eine Liste oder ein Tuple ist. An der Stelle fehlt mir grade die Idee wie ich das ganze flexibler gestalten kann. Die Job an sich werden in eine Queue gelegt und später von entsprechenden workerthreads abgearbeitet, die Ausschnitte habe ich mir hier aber mal gespart, da sie nichts mit dem eigentlichen Problem zu tun haben.

    Ich hoffe der ein oder andere kann mir entsprechende Tipps geben. Wahrscheinlich stehe ich gerade einfach nur auf dem Schlauch und habe die Lösung quasi schon vor Augen.

    Danke für eure hilfe

    gruß

    ardani

  • Verwendung einer beliebigen Anzahl von Parametern für den Aufruf einer Funktion? Schau mal ob du hier fündig wirst!

  • Vielleicht hilft das:
    http://stackoverflow.com/questions/1769…wargs-in-python
    http://www.saltycrane.com/blog/2008/01/h…args-in-python/
    http://thepythonguru.com/python-args-and-kwargs/


    PS: Zu viele Threads zu haben kann ausbremsen. Threads sind eigentlich keine schöne Lösung, besser wäre multiprocessing.

  • ok, ich sagte ja vermutlich stehe ich auf dem Schlauch. Habe die Methode jetzt angepasst:

    Code
    def getJob(self):
            """Die Methode get-Job hat als Rückgabe die Funktion und die Argumente, je nach Anzahl dieser"""
            return functools.partial(self.function, *self.args, **self.kwargs)

    und sie liefert mir bis jetzt zumindest genau das was ich erwarte... Das Multithreading nicht in allen Fällen die beste Lösung ist weiß ich, sollte in meinem Szenario mit parallelen I/O Operationen aber erst einmal reichen. Geplant ist es die weiteren Klassen noch entsprechend anzupassen, damit auch Multiprocessing ermöglicht wird, liegt u.a. daran das Multithreading zunächst einfacher zu implementieren war. Die Anzahl der Threads habe ich aktuell mit 4 begrenzt.

    Dann kann ich auch konkrete Performancetests zwischen beiden Methoden machen.

    Danke für den Hinweis.

    Einmal editiert, zuletzt von ardani (16. März 2016 um 20:26)

  • Hallo,

    Zitat

    Das Multithreading nicht in allen Fällen die beste Lösung ist weiß ich, sollte in meinem Szenario mit parallelen I/O Operationen aber erst einmal reichen.


    Wenn du non-blockign I/O brauchst, dann schau dir mal das asyncio-Modul an. Dies ist seit Python 3.4 in der Standardbibliothek und genau dafür gemacht.

    Und kennst du Celery? Das kann eigentlich das, was du gerade selber implementierst (sofern ich richtig verstanden habe, was du vor hast).

    Gruß, noisefloor

  • Ich werde in den nächsten Tagen versuchen mich in die Module bzw. Implementationen einzulesen und schauen ob diese für mich einsetzbar sind oder nicht vllt. sogar oversized für das sind was ich machen möchte.
    Kurz zur Erklärung:

    Im Endeffekt ist meine aktuelle Implementation ein Zusammenspiel aus aktuell drei Modulen.
    Zum einen ein Workermodul, diese holt sich Jobs aus einer Queue und arbeitet diese ab. Je nach Ergebnis wird u.U. eine weitere Funktion aufgerufen, das Ergebnis zurück geschrieben oder ein Errorhandling durchgeführt, z.B. erneutes Ausführen des Jobs bei Timeout Fehlern usw...
    Das zweite Modul ist eher ein steuerndes Element, prüfen ob die Threads hängen, starten und beenden der Threads, verwalten der Queue. Wird auch als Schnittstelle zwischen der Applikation an sich und den WorkerThreads verwendet.
    Das dritte Element ist die oben beschriebene Job-Klasse, im Endeffekt werden diese erzeugt, durch den "Manager" ggf. validiert, auf die Queue gelegt und später von den Workerthreads abgearbeitet.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!