Das deutsche Python-Forum

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.

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

Gerade der Punkt mit der Performance würde mich interessieren. In PyLucid gibt es sowas jedenfalls noch nicht und ich überlege halt, ob ich es einbauen sollte...

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.

Ä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.

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?

Hab was dazu gefunden:

wsgi.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.

von http://code.google.com/p/modwsgi/wiki/P ... dThreading

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

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.

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.

Leonidas hat geschrieben:

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.

Ä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.

Meinte ich doch, sorry :=)

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.

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...

Wenn die Geschichte über threading.local keine Nachteile hätte, wäre das nun eine Alternative.