Was haltet ihr von der Methode über threading.local Objekt global zur Verfügung zu stellen?
Beispielsweise so: http://code.djangoproject.com/wiki/Cook ... alsAndUser
Der normale Weg ist Objekte an's request Objekt zu packen und request überall hin mit zu übergeben. Das sollte auch beibehalten werden. Aber zur Not kann man dann über die Threadlocals ans passende Objekt kommen.
django: Globale objekte durch threading.local ?
Es vereinfacht jedenfalls einige APIs wenn mans' schick macht. Du könntest aber auch das Standalone-Modul 'local' nutzen, welches in Werkzeug implementiert ist. Das bietet schöne APIs an und kann auch einiges mehr, als nur context locals zu definieren.
Man kann damit jedoch schöne Sachen anstellen, aber weiß ich nicht wies' sich mit der Performance verhällt, da du ja jedes mal zugriffe auf nen thread hast.
MfG EnTeQuAk
Man kann damit jedoch schöne Sachen anstellen, aber weiß ich nicht wies' sich mit der Performance verhällt, da du ja jedes mal zugriffe auf nen thread hast.
MfG EnTeQuAk
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ähm, thread.local hat keine Zugriffe auf irgendwelche Threads sondern auf die Variablen in deinem aktuelen Thread. Dazu ist es ja auch da. Wenn du globale Variablen hast, könnten die von mehreren Threads verarbeitet werden.EnTeQuAk hat geschrieben:Man kann damit jedoch schöne Sachen anstellen, aber weiß ich nicht wies' sich mit der Performance verhällt, da du ja jedes mal zugriffe auf nen thread hast.
Wer weiß wie Django über FCGI mit Threads läuft? Wird da ein Thread pro Verbindung gestartet oder hat es einen Thread-Pool mit Worker-Threads die eine Queue abarbeiten?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Hab was dazu gefunden:
Hab noch zum Thema django rumgesucht, aber nicht wirklich was gefunden.
EDIT: Hab mal in django-users nachgefragt: http://groups.google.com/group/django-u ... 1538eb9023
von http://code.google.com/p/modwsgi/wiki/P ... dThreadingwsgi.multithread
This value should evaluate true if the application object may be simultaneously invoked by another thread in the same process, and should evaluate false otherwise.
wsgi.multiprocess
This value should evaluate true if an equivalent application object may be simultaneously invoked by another process, and should evaluate false otherwise.
Hab noch zum Thema django rumgesucht, aber nicht wirklich was gefunden.
EDIT: Hab mal in django-users nachgefragt: http://groups.google.com/group/django-u ... 1538eb9023
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Irgendwie muss ich sagen das vermeiden von Funktionsparametern mir alles andere als gefällt, damit hat man dann quasi globals nachgebaut und oha, das zu debuggen darf dann jemand anders machen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ne, also es soll auch nicht zum Standard werden. Ganz im gegenteil. Es sollte die Ausnahme bleiben.
Ich möchte damit page_msg global verfügbar machen. Sollte aber dann nur Verwendung finden, wenn man halt kein request Objekt zur Hand hat.
Ich möchte damit page_msg global verfügbar machen. Sollte aber dann nur Verwendung finden, wenn man halt kein request Objekt zur Hand hat.
Meinte ich doch, sorry :=)Leonidas hat geschrieben:Ähm, thread.local hat keine Zugriffe auf irgendwelche Threads sondern auf die Variablen in deinem aktuelen Thread. Dazu ist es ja auch da. Wenn du globale Variablen hast, könnten die von mehreren Threads verarbeitet werden.EnTeQuAk hat geschrieben:Man kann damit jedoch schöne Sachen anstellen, aber weiß ich nicht wies' sich mit der Performance verhällt, da du ja jedes mal zugriffe auf nen thread hast.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Genau so eine Situation habe ich nun. Ich habe mehr Logik ins Model gepackt. z.B. beim löschen eines Model Eintrags möchte ich feedpack über page_msg geben. Also muß ich nun page_msg übergeben...jens hat geschrieben:Ich möchte damit page_msg global verfügbar machen. Sollte aber dann nur Verwendung finden, wenn man halt kein request Objekt zur Hand hat.
Wenn die Geschichte über threading.local keine Nachteile hätte, wäre das nun eine Alternative.