[mod_python] telling mod_python to exit its children

hi graham

thanks for the pointers.  it seems from your description that Vampire
is doing the same as i am with my reloader module.  from the details
you mention, it seems you're also running against the similar
weirdness.  i'll check it out soon.  however all i can hope to find
there is a less buggy version of the approach i'm already trying.

but what i'm trying to do now, is different, is to bypass all that,
really.  i want to find out how to communicate to mod_python to exit
all its current pool of children (perhaps not all at the same time,
but at least to mark them as "not runnable").  it's a trivial approach
to that problem, which will certainly work well in all cases (in a
non-threaded apache).

if it's not in there already, i will probably add that feature,
because it would be a much cleaner and easier way to implement this
automatic reload, and it would work with all frameworks, and perhaps
it could even find other uses.

cheers,




On 5/21/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote:
> Are you using basic content handlers or are you using a package on
> top of them such as mod_python.publisher, mod_python.psp or any
> third party packages for templating such as Cheetah etc?
> 
> Depending on what you are using it may be able to be refactored to
> work on top of Vampire which has a quite well developed module
> importing and reloading system which doesn't suffer the sorts of
> problems that a lot of such systems do. When used appropriately,
> Vampire is able to detect when a child sub import at multiple
> levels below the actual request handler has changed and reload
> automatically the request handler and anything below it down to
> the level of the modified module.
> 
> By reloads being automatic in this way, you avoid having to set
> special flags or cookies to trigger reloads or work out how to
> shutdown specific Apache processes.
> 
> The only known area of problems so far, which will occur with any
> reloading scheme, is where caching of class type objects is done
> for later type comparison. This is a problem because of the fact
> that the actual class definition in the original module can be
> replaced and so a cached type object will no longer be valid. With
> care this can be avoided though.
> 
> You might therefore have a quick glance at Vampire to see how it
> matches with the underlying way you implement handlers. If your
> handlers can easily be rehosted on top of Vampire then it may be
> a way forward. Even if it doesn't look straight forward let me
> know and we can look at it further as Vampire is generally flexible
> enough to do things that on first pass don't look possible to
> someone not familiar with it.
> 
> Be warned that documentation on the module reloading is minimal
> at this point. There is a little bit in the overview with more
> in the changes file.
> 
> Vampire is located at:
> 
>    http://www.dscpl.com.au/projects/vampire
> 
> If you are truly interested in giving it a go, happy to direct
> you.
> 
> Graham
> 
> 
> On 21/05/2005, at 11:52 PM, Martin Blais wrote:
> 
> > hi
> >
> > i've been working on a web app framework, and one of the
> > essential features that i need to work well is to be able to
> > simply save a new source file (while in debugging mode, set by a
> > flag in my config file) and for all the modules to be
> > appropriately reloaded (there is no way i would restart apache
> > everytime i change the code...).  i'm using lots of 3rd party
> > libraries and my code is spread out in many packages and modules,
> > so i found that the trivial reload approaches do not work well.
> >
> > so thinking i was a smart cookie i've been fiddling quite a bit
> > and solved a lot of the problems and it pretty much works (but it
> > wasn't as easy as i thought), except for that occasional rare
> > case where something strange still happens (due to some residual
> > global state in the modules i didn't unload or what-not).  now i
> > could spend more time on that bug, but i've already spent a
> > considerable amount of time with this, and the solution is not
> > very clean anyway (fiddling with the sys.modules by hand...) and
> > i'm getting the feeling that taking a lower-level approach might
> > just be cleaner and easier.
> >
> > Some questions:
> >
> > 1. in a handler, is there a way to tell apache to exit the child
> >    currently handling the request and to rerun the request it
> >    another/a new child?
> >
> > 2. or is there a way to tell apache to exit all its pool of
> >    children, so that new request only get handled by new/fresh
> >    child processes?
> >
> >
> > I saw REQ_EXIT in apache.py, but it doesn't appear anywhere else
> > in the code, and is marked legacy.  Also, according to the
> > documentation, returning DECLINED doesn't appear to indicate that
> > apache will retry the same handler on a different child, but
> > I may be reading wrong.
> >
> > any pointers appreciated.
> >
> > cheers,
> >
> > _______________________________________________
> > Mod_python mailing list
> > Mod_python at modpython.org
> > http://mailman.modpython.org/mailman/listinfo/mod_python
> 
>