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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
