2009/3/21 Nimrod A. Abing <[email protected]>: > > On Sat, Mar 21, 2009 at 4:09 PM, Florian Bösch <[email protected]> wrote: >> >> On Mar 20, 10:23 pm, Graham Dumpleton <[email protected]> >> wrote: >>> No it doesn't. You have also made other statements which show you are >>> making wrong assumptions about how it works. >> >> If I issue an os.kill(os.getpid(), signal.SIGINT) the ongoing request >> is still served by this process. In the context of wanting a request >> be served from the *newly started* process this is quite usless, which >> Is why I suggested an alternative configurable behavior. > > I had the exact same problems described by the OP while using the > monitor.py. At any given time I could make changes to several files. > Some of the changes may be dependent on each other and cause problems > if I forget and issue :w instead of :wa from my editor.
If you don't write all the changes, you are going to have a problem not matter what mechanism you use as you are going to have an inconsistent code base. That is a user problem, not a problem with the monitor script. As explained in prior mail, because mod_wsgi does lazy loading of application, it doesn't matter that daemon shuts down on first edit, as it will not reload the WSGI application until the next request you trigger. If you haven't written all your code before making next request, that is your own problem. > I was looking > for an alternative way of triggering a reload and the SIGINT trick > inside a single-process daemon was the first thing I tried. I have > always wondered what happens when SIGINT is signalled to the daemon > process. Does it stop the process immediately, leaving code after the > os.kill() call unexecuted? No, it performs an orderly shutdown of the daemon process, attempting to wait for all current requests to finish before actually killing the process. As a fail safe however, if the active requests take more than the shutdown timeout, default of five seconds, then it will forcibly kill off the process. > Apparently the Django view executes just > fine, I have code after os.kill() that does a redirect and it seems to > work. > > Anyway, +1 on having an alternative configurable behavior. Maybe a > "developer mode" where each request is handled by a newly spawned > daemon process and it could work in similar fashion in embedded mode. > This is regardless of whether or not code has changed. During > development, I don't really care about performance issues caused by > file system access or process creation overheads. > > This sort of behavior is no different from just using plain CGI but > the idea here is that you can set up your development server *exactly* > as you would for production with the exception that you can have a > configuration option that enables "always reload" behavior. That way > all you would have to do is copy over the configuration from > development server to production server, minus the "always reload" > switch. The current mechanisms do what is required, it is the understanding of how it works which is wrong. Nothing new is needed. The only case where you might want to do something different is the background task example I mentioned in prior message, and for which I indicate an alternative you could use. At the moment all I am seeing from original poster is speculation that it isn't going to work how they need it to and no actual indication that they have actually tried it and can show it has a problem. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
