On Sat, Mar 21, 2009 at 5:13 PM, Graham Dumpleton <[email protected]> wrote: > > 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.
I now realize that if I did a :w instead of :wa I do notice that and issue a :wa. In which case the updated code is reloaded by the monitor script anyway and the possible problems caused by incomplete writes go away. > 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. On a testing server that I have, this has caused me a lot of grief because the FTP connection I use can cause a partial upload. What I did was increase the time between file modification time checks in the monitor. >> 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. That's a relief. >> 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. You're right. Theoretically it *could* cause problems but in practice, from what I have experienced so far anyway, it's really no big deal and the current methods of reloading are more than adequate. -- Best Regards, Nimrod A. Abing W http://arsenic.ph/ W http://preownedcar.com/ W http://preownedbike.com/ W http://abing.gotdns.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
