On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald
<wkornew...@gmail.com> wrote:
> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote:
>> Here's an example of a thread-safe view that works happily with just
>> one instance:
>>
>> ---- 8< ----
>>
>> class MyView(object):
>> def __init__(self, queryset, template='bar.html'):
>> self.qs = queryset
>> self.template = template
>>
>> def __call__(self, request, id):
>> instance = get_object_or_404(self.qs, id=id)
>> return direct_to_template(request, self.template, {'object':
>> instance})
>>
>> # ...
>>
>> url(r'^foo/(?P<id>\d+)/', MyView(queryset=Foo.objects.all(),
>> template='foo.html')),
> This is not at all thread-safe because all requests share the same
> view instance and thus the same state. Shared state is not thread-safe
> (unless you introduce some locking mechanism which is not an option
> here). Thread-safety can only be guaranteed if every thread has its
> own state. In other words, every request needs his own View instance.
You don't seem to get how threading works.
There is no state in this object past the assignments in __init__.
These are thread-safe as there is only one instance of the object.
Variables in local scope are always thread-safe as reetrancy grants
you a new local scope every time it enters a function.
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
