On Sat, Nov 14, 2009 at 4:15 AM, stevecrozz <[email protected]> wrote:
> I tried to reopen this bug http://code.djangoproject.com/ticket/9286,
> but apparently that's a no-no since it was closed as invalid by a core
> developer.
>
> I'd like someone to take another look at it since I think Jacob didn't
> understand the bug because the original poster's example was
> ambiguous. I supplied my own, more concise example which I'll outline
> here. Use the development server to serve any project where a view
> tries to start a background process using the subprocess module:
>
> import subprocess
>
> def my_view(request):
> subprocess.Popen(['/bin/sleep', '5'])
> return HttpResponse(u'That sure took a while!')
>
> This example should start a background process which would run for 5
> seconds. Since its a background process, it should not block (but it
> still does), try it from the cli:
>
> $ python -i
>>>> import subprocess
>>>> subprocess.Popen(['/bin/sleep', '30'])
> <subprocess.Popen object at 0xb77c606c>
>
> This example does not block, it properly starts the background process
> and returns its Popen object immediately.
Ah - but so does your example. Try putting some debug in your original view:
def my_view(request):
subprocess.Popen(['/bin/sleep', '5'])
print "Hi there!"
return HttpResponse(u'That sure took a while!')
When you request this view, the call to subprocess doesn't block - the
print statement is issued immediately. However, the web server process
will wait until all subprocesses have completed before it serves the
response to the browser.
The fact that it is waiting for the process to finish doesn't block
the server either - it can serve other requests while it is waiting
for the first request to complete it's subprocesses.
Personally, I agree with Jacob - I don't see this as much of a
problem, for several reasons.
Firstly, Django's development server isn't multithreaded, and it isn't
intended for production use. I'm almost in favour of having
performance problems like this in the development server, specifically
to act as a discouragement for production use.
Secondly, while I haven't actually tested subprocess behaviour on
"real" webservers, I'd be willing to bet that at least some
implementations will do exactly the same thing that Django's webserver
is doing. After all, all we're doing here is *not* making the
subprocesses daemons by default.
Lastly, If your application is relying on HTTP to kick off an
orphan/daemon subprocesses to do some background processing, I
strongly suspect that UR DOIN IT WRONG. HTTP requests are supposed to
be shortlived. Spawning long lived behaviour out of a short lived
request isn't a really good idea. If you want a web request to spawn
some long-lived processing, you should probably be looking at
implementing a Message Queue for your app. There are plenty of options
out there, ranging from a ghetto queue (write a "job" to the database,
and have a cron job to pick up and run the jobs) all the way up to all
singing, all dancing projects with graphical management interfaces
etc.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=.
