Kicking off threads could be a solution, if you want your time- consuming_function to run in the same process(es) as django. Otherwise, you'll need to either create new processes or use some inter process communication solution (socket, http, message queue, ...)
In the first situation, make sure you that you either don't access the database via the django ORM, or manage the db connection yourself. Django closes db connection when the HTTP Response is returned, using signals. If you play with the db after the request/response cycle has completed, django will be unaware of your db connections and won't close them. Rodrigue On Jul 9, 9:59 pm, Javier Guerra <jav...@guerrag.com> wrote: > On Thu, Jul 9, 2009 at 3:30 PM, Javier Guerra<jav...@guerrag.com> wrote: > > maybe is it possible to use signals like this? i haven't checked the > > source, but it seems plausible to have them dispatched _after_ the > > request is serviced. > > no, it doesn't work like that. also, it seems that a custom > middleware wouldn't work, given the way the WSGIHandler() is written > (the last thing it does is to return the response content). > > go the message queue way. > > -- > Javier --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
