Re: [Mod-c-users] Fwd: some stuff

[Gonzalo A. <gon...@gm...>]

On 8/24/06, Matej Urbas <mat...@gu...> wrote:
> On Thu, 2006-08-24 at 12:55 -0300, Gonzalo Arana wrote:
> > I've changed my mind on this a little bit.  I've wrote this:
> >
> > 1) EHTMLAllowOnDemand on|off: if set to off, every ehtml must be LoadEHTML'ed.
> > 2) EHTMLCacheAutoRefresh on|off: if set to on, cached ehtml entries
> > will be autorefreshed if file has changed (mtime & size are checked).
> >
> > How does this sound to you?
>
> Oh, the AutoRefresh stuff... Yeah... Well, this will be a more tricky
> thing. You see, HTTPD creates child processes to handle web pages in a
> secure manner (perhaps there are other reasons to it, but it's not
> important). So, every request is processed in those child processes. The
> catch is that whenever we Refresh an EHTML library, it would happen only
> in that particular child process that received the request (other child
> processes' caches would not be refreshed).
>
> After a selected amount of precessed requests HTTPD simply kills those
> child processes and recreates them instantly afterwards (to prevent
> memory corruption etc...) - this is also configured in the httpd.conf
> file (I have it configured that HTTPD respawns child processes after
> every 20.000 requests).
>
> Anyways, those newly recreated processes would again have the cache as
> was created at httpd's startup time! You see, whatever
> refreshing/caching there happened at run-time would be nulled when
> respawning of processes happens.

yes, I am aware of that, same thing happends for mod_rewrite cached
lookups for plain_text & dbm maps.

> This does not mean that it doesn't make sense to refresh/cache
> libraries. I just wanted to tell you what happens in httpd.

I think it is a good thing to save dlopen/dlsym work for
MaxRequestsPerChild times.  Automatically cached entries will save a
lot of CPU time if we don't want to force user to LoadEHTML all of his
applications.

> Well, at least I think this is what happens in httpd :-D I could be
> wrong :-P

We could both be wrong :D.

Cheers,

-- 
Gonzalo A. Arana