Hi Tom,
On Friday, September 20, 2013 5:04:41 PM UTC+2, Tom Evans wrote:
>
> On the other hand each call to get_cache('foo') now requires access to
> TLS. TLS is sloooow. Going through something slow to get to something
> that is supposed to be a speed up...
>
You are making a good point, even though I do think that TLS is still way
faster than anything waiting for IO (python has a python implementation of
threading.local and a c implementation).
Would it be better to leave the API and semantics of get_cache alone
> and provide a new way of accessing caches through the request object,
> leaving them cached on the request object for the duration of the
> request, and thus avoiding the need of TLS.
>
I would prefer to have one API, but I think it would be okay for cache
backends them self to specify that the shouldn't be put into a thread local
storage (probably via a simple attribute). Does that sound like a solution
to you? LocMemCache seems to be a candidate for that.
> Requests aren't shared between threads, and so a
> per request cache would be inherently thread safe.
>
The same argument holds true for let's say django db connections; but I
doubt it's gonna fly; eg passing request into get_cache as storage object
seems somewhat nasty (at least as long as we name it request ;))
> It seems more sensible to hook something that has the lifetime of the
> request to the request, rather than stick it in TLS, keyed to the
> thread serving the request.
>
Jupp, sadly I don't see a sensible way around thread local storage here :(
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
