Friday, January 30, 2015

Re: Do Signals block Django process?

The number of threads is determined by the number of workers in your process that is serving the application, not Django itself.

For example, if you are using uWSGI to serve the application, then you have a parameter "workers" in its initialization file that sets the number of process to spawn and handle incoming requests.

As far as I know, signals are processed "in sync", that is, the original function is stopped until the signal has been processed. If you need async functionality you would need to take a look at celery or something along those lines.

On Fri, Jan 30, 2015 at 1:13 PM, Tobias Dacoir <falc410@gmail.com> wrote:
I just added django-badges to my project. Basically it can award Badges if Users fullfill certain requirements. For this, everytime I call user.save() django-badges receives the post_save() signal and starts checking.

Now my project is similar to an online quiz, where users submit forms to answer questions. Right now I only have tested it locally and I'm not sure how to simulate multiple users accessing the page at the same time.

When later run on production in combination with a webserver, will Django spawn a new thread for each connection / user? Or will there be only one thread, so if two users are accessing the website, the 2nd has to wait until the request from the first user is processed?

Also what about my signal to process the badges. If I have a function that calls user.save(), which then signals to the badges module, will the execution of the original function stop until the signal has been processed or not?

def myView(request):
   do_something
()
   request
.user.save()
   
# signal emitted
   
# ...
   render
(view)

So in this case, will the view be rendered immediately or only after the receiver for the signal has finished doing it's work? In my case I don't really need it to be asynchronous as long as the badge checking is fast enough and doesn't block the website for other users.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f3b2f9dd-4681-48a1-8d49-79f73d45d0eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALn3ei1CTR1-wMjqGwWv-cMp1wHhaPV0YzJm65Mw8-wLYyoUuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment