On Sat, Nov 14, 2009 at 1:01 PM, Stephen Crosby <[email protected]> wrote: > Thanks for the response Russell, > > We can get into exactly what I'm doing if we need to, but for now lets just > assume that I've thought this through fairly thoroughly and I do in fact > want to start background processes from certain very specific web requests. > We can certainly get into the details if I have to defend my rationale.
Ultimately, you're the person who has to live with your code, so I'll defer to your judgement. However, put me on record as officially advising against it :-) > The development server isn't for production use. This is true, and I can > live with that, but it makes this type of development more cumbersome (this > is something I'd want to test in development before I deploy it), if its a > huge design change then maybe its not worth the effort to carry out, but I'm > not convinced yet. Maybe the development server can't or shouldn't be made > to fit my needs, but I'd still like to look at that rationale more closely > and add that information to the bug report once the community comes to a > more full decision. Django's development server isn't doing anything specific here with regards to subprocesses. We're just providing a WSGI handler to Python's BaseHTTPServer. Waiting for subprocess to terminate before terminating a parent process is not an uncommon behaviour, and that is exactly what BaseHTTPServer is doing in this case. There might be ways to fix this, but I doubt they will be simple. I would also like to repeat a comment from my last mail - have you actually confirmed that your deployment platform of choice will actually support the approach you are taking here? I haven't tested this myself, and I can't find any obvious documentation to this effect, but I would not be in the least bit surprised to find that a long lived subprocess is a one-way path to server resource starvation. > I'm not sure I understand the second argument about single-threadedness yet. > Aren't we talking about multiple processes and not multiple threads? Can't > one process start another process without needing multiple threads? I raised this point because historically, problems with multiple/long lived requests in the Django development server are closely followed by requests to make the development server multithreaded. The Django core has repeatedly rejected these suggestions, specifically because we don't want Django's development server to be used in production, and this is one way to make sure that this request is honoured. I was trying to point out that in this case, while you are waiting for the subprocess to complete, you actually can serve other responses. It isn't locking anything - it's just waiting for the subprocess to complete before the server completes the response. > If anyone has a better idea for starting background processes from django, > I'd be happy to consider them for my project. Sure - and my original response contains 2 of them: 1) Use a message queue :-) 2) Start your subprocess in daemon mode. 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=.
