mod-c-users

Re: [Mod-c-users] some stuff

[Matej U. <mat...@gm...>]

On Thu, 2006-08-24 at 09:57 -0300, Gonzalo Arana wrote:
> I agree about making it optional.  I am thinking in something like:
> Cache non LoadEHTML'es files as well, but those are checked on each hit.

AutoCacheEHTMLFiles directive?

There is a catch with the upper directive:

If we decide to use the directive on a per .htaccess basis, we'll have
to make sure that every access to lib_cache is synchronized - regardless
of whether the option is turned off for all directories or not (the
catch is it's hard to know whether the option is turned off for all
directories or not...) Do you see what I'm trying to say?

But if we make the upper directive global, we could know for sure that
no libs will be added at any time - hence, we could use the current way
of handling with the cache.


In any event, you are right with synchronization: if we decide to put
EHTML files into the cache at 'runtime', we'll have to add some
functions (or modify existent - although I prefer the former) which
would work with the lib_cache in a thread-safe manner.

> 
> Security comes to my mind in order to tell me NOT to process ehtml
> requests that are not LoadEHTML'ed (not sure why yet).  Perhaps we
> could disable (via an apache directive) on-demand dlopen/dlsym.

AllowLoadedEHTMLsOnly directive?

Sure, this is a very important feature. EHTML is dangerous and perhaps
some people would not trust everyone to add their EHTML applications
onto their web servers...

What about a DontExecuteEHTML directive (on a per .htaccess basis)? It
could prevent execution of EHTML in selected directories.

> WIth current scheme, you are right.  I was not aware that I was
> thinking in caching all requests (my mind works in misterious ways
> :D).  If we cache ehtml dlopen/dlsym on demand, this should be a
> per-server cache.

Well, there will be as many copies of the cache as there are child
processes created by HTTPD.

There is no problem with creating one at configuration-time - it will
get copied by the OS when child processes are hooked. (I guess :P)

> If we cache per-request, we do have to worry :(.  Sory to bring this
> up again :(.

Yeah, sure you're right. That's what 

> 
> Perhaps shall we shift this design threads to mod-c-dev mailing list?

I have mailed a copy of this mail to the users list (I think we won't
have a lot of users anyways, so we can use the users list for stuff like
that). I prefer to have as little mailing lists to worry about as
possible ;-)

I will mail the users list from now on.


Enjoy,
---
Matej

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

[Matej U. <mat...@gm...>]

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.

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

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


Enjoy

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

Re: [Mod-c-users] some stuff

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

On 8/24/06, Matej Urbas <mat...@gm...> wrote:
> On Thu, 2006-08-24 at 09:57 -0300, Gonzalo Arana wrote:
> > I agree about making it optional.  I am thinking in something like:
> > Cache non LoadEHTML'es files as well, but those are checked on each hit.
>
> AutoCacheEHTMLFiles directive?
>
> There is a catch with the upper directive:
>
> If we decide to use the directive on a per .htaccess basis, we'll have
> to make sure that every access to lib_cache is synchronized - regardless
> of whether the option is turned off for all directories or not (the
> catch is it's hard to know whether the option is turned off for all
> directories or not...) Do you see what I'm trying to say?

mmm you mean synchronized due to multi-thread access?  If it is a
per-server variable, I believe there is no need for syncrhonization.

Regards,

-- 
Gonzalo A. Arana