2009/3/21 Florian Bösch <[email protected]>: > > 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.
If a monitor thread is being used to trigger that os.kill(), there needn't even by an 'ongoing request' as you call it. They are two totally separate events in time which run independently. When the monitor thread triggers an os.kill(), because it has detected a file change, any request which arrives after that point will be handled by new incarnation of the process. If there so happened to be a request active at the time the monitor thread found a file had been changed, then it obviously if left to run its course. The only caveat in this is that there is (by default) a one second window in which a request could arrive and which a file change could have been made and it hasn't yet been detected. Since you would only ever want to use that restarting code on a development system, I fail to see why having that one second window would be an issue. You would have to be some super human coder to consistently breach it by being able to save a file and then flick over to your browser and trigger a refresh all in under one second. As to use of os.kill() in response to a specific request URL. The whole point is that that is a special URL that would only be accessed when you want to remotely trigger a restart of the daemon process. It is not the intent that you be using some sort of WSGI middleware that is applied to all requests and does its own check for modified code on every request to every URL before triggering the real WSGI application. As you note this will not work and it isn't supposed to be able to work that way. As I said before, although such a check could be implemented internally to mod_wsgi to do what you want because it could hook into the low level handshake that goes on between Apache child server process and daemon process to determine if request can proceed or daemon process needs a restart, before actually sending through the request, I don't see it as a wise or worth the effort of doing it. The big danger with such a feature is that people will enable it and leave it enabled in a production system, which would then overly impact the performance of their system. It frankly doesn't give you any real benefit over the monitor thread example. Now back to the monitor thread, the only justification you seem to have against it is 'When doing development I don't want my code to bounce up and down until I've done editing.' There are a few things here you perhaps don't understand. The main one is that mod_wsgi by default performs lazy loading of the WSGI application. This means the WSGI application is only loaded into a daemon process when the first request for it arrives. What this means is that although that monitor thread will shutdown the daemon process, it only gets restored with an idle and empty process, no WSGI application will be automatically loaded, nor will the monitor thread be restarted automatically. So, what does it matter if it shuts it down when the first edit is detected, since you aren't presumably going to make any request against it any way until you have finished all your edits. When you have thus finished your edits and you make your request, only then will it load the WSGI application again with all the code changes. Because lazy loading is being relied upon, you can't therefore configure mod_wsgi to preload your application, which when doing development wouldn't nornally be done anyway. This is because preloading would cause monitor script to start again and so every change to a preloaded file would cause process to bounce. If for some reason you really do want to also use preloading, then you can change the code so as not to use os.kill() and instead, provided you change code so it has reference to WSGI script file module, reset the __mtime__ variable in the WSGI script file to zero. This will have the affect of not restarting the daemon process when first change detected, but will delay a restart until the next request arrives. So, if you can live with the one second window still, this will achieve your goal of only doing the restart when next request arrives. The only sane reason I can come up with as to why you would want this slightly different behaviour is that your application runs its own background threads which do work and which you want to have running all the time, and as such bringing down the daemon process on first edit, with WSGI application not being reloaded automatically, would prevent. 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 -~----------~----~----~----~------~----~------~--~---
