django: Globale objekte durch threading.local ?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 2. Juni 2008, 13:24

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.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Montag 2. Juni 2008, 14:02

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
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 2. Juni 2008, 14:03

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

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 2. Juni 2008, 14:07

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?
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 2. Juni 2008, 14:31

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

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 2. Juni 2008, 14:59

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 Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 2. Juni 2008, 15:10

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.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Montag 2. Juni 2008, 16:05

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 :=)
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 4. Juni 2008, 20:17

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.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten