RE: PerlOptions Clone/Parent in mp2
> With something like a http://foo/*> block, mod_proxy does > the right thing ( and the simple ) of using the power of > ap_walk_config() to handler the parsing of the contents of the block. [...snip...] > Reason blocks can't do that is becasue we can't let httpd try and > parse perl code and make any sense of it. If you look closely, a > block simply slurps all its contents and feeds it to perl for > processing. Ah...I see...it's the MP_CMD_SRV_RAW_ARGS_ON_READ which translates into AP_INIT_RAW_ARGS with the all-important EXEC_ON_READ flag that allows you to waylay the configuration file on the way in. Otherwise the directives are partially processed and constructed into a tree, which you don't want. Turns out mod_macro does the same thing. Doesn't apply to my code, thank goodness. thx, mma
RE: PerlOptions Clone/Parent in mp2
On Thu, 2003-06-12 at 02:59, Marc M. Adkins wrote:
> > > The code to implement blocks (e.g. ...) in
> > config files is
> > > pretty gnarly, too. I know it's already there for , it's
> > one of the
> > > places I looked when I was considering doing one of my own and
> > wanted to see
> > > an example. The Apache framework is pretty strong for putting in new
> > > directives, but not so much for adding new blocks.
> >
> > Actually you can't quite do that in a 3rd party module. Currently
> > the pools
> > are internal to mod_perl. Making this customizable will require
> > adding hooks
> > to the internal tipool mechanism. When I wrote the above
> > pseudo-config I was
> > suggesting an internal support for these.
>
> I was actually not figuring to do it myself. ;)
>
> I was commenting on the code required to implement things like or
> . I've since queried the httpd-dev list and the 'official' example
> is in the source for mod_proxy (with a caveat that a three-pass config file
> parser may necessitate further changes at some point). It appears to be a
> lot simpler than the parsing that mod_perl is doing. I was wondering...is
> there a specific reason mod_perl implements the way it does or is it
> just code inertia?
With something like a http://foo/*> block, mod_proxy does
the right thing ( and the simple ) of using the power of
ap_walk_config() to handler the parsing of the contents of the block.
You might want to do the same thing for something like ,
allowing things like
MaxTiPoolConn 10
MaxTiPoolConn 20
And have each directive in the block be handled like regular
apache directive with all the cool benefits of configuration merging,
etc.
Reason blocks can't do that is becasue we can't let httpd try and
parse perl code and make any sense of it. If you look closely, a
block simply slurps all its contents and feeds it to perl for
processing.
Hope this makes sense.
> mma
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
RE: PerlOptions Clone/Parent in mp2
> > The code to implement blocks (e.g. ...) in > config files is > > pretty gnarly, too. I know it's already there for , it's > one of the > > places I looked when I was considering doing one of my own and > wanted to see > > an example. The Apache framework is pretty strong for putting in new > > directives, but not so much for adding new blocks. > > Actually you can't quite do that in a 3rd party module. Currently > the pools > are internal to mod_perl. Making this customizable will require > adding hooks > to the internal tipool mechanism. When I wrote the above > pseudo-config I was > suggesting an internal support for these. I was actually not figuring to do it myself. ;) I was commenting on the code required to implement things like or . I've since queried the httpd-dev list and the 'official' example is in the source for mod_proxy (with a caveat that a three-pass config file parser may necessitate further changes at some point). It appears to be a lot simpler than the parsing that mod_perl is doing. I was wondering...is there a specific reason mod_perl implements the way it does or is it just code inertia? mma
Re: PerlOptions Clone/Parent in mp2
Marc M. Adkins wrote: However I think it is possible to make the architecture more flexible to allow pools sharing across specific vhosts, or even location containers (if the scope is set to be only for the handler). e.g. something like: #base server # parameters # parameters PerlUseTiPool A PerlUseTiPool A PerlUseTiPool B PerlUseTiPool B Yeah, that would do it. I don't know how many people will need this, probably not so many. And there might be a sufficient work-around in those rare (?) cases involving multiple Apache instantiations and a proxy server to tie it all together. Something like the high-volume configurations I've seen documented, only with one mod_perl-enhanced server for each TIPool. The code to implement blocks (e.g. ...) in config files is pretty gnarly, too. I know it's already there for , it's one of the places I looked when I was considering doing one of my own and wanted to see an example. The Apache framework is pretty strong for putting in new directives, but not so much for adding new blocks. Actually you can't quite do that in a 3rd party module. Currently the pools are internal to mod_perl. Making this customizable will require adding hooks to the internal tipool mechanism. When I wrote the above pseudo-config I was suggesting an internal support for these. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: PerlOptions Clone/Parent in mp2
> However I think it is possible to make the architecture more > flexible to allow > pools sharing across specific vhosts, or even location containers (if the > scope is set to be only for the handler). e.g. something like: > > #base server > > > # parameters > > > # parameters > > > > PerlUseTiPool A > > > PerlUseTiPool A > > > > PerlUseTiPool B > > > PerlUseTiPool B > Yeah, that would do it. I don't know how many people will need this, probably not so many. And there might be a sufficient work-around in those rare (?) cases involving multiple Apache instantiations and a proxy server to tie it all together. Something like the high-volume configurations I've seen documented, only with one mod_perl-enhanced server for each TIPool. The code to implement blocks (e.g. ...) in config files is pretty gnarly, too. I know it's already there for , it's one of the places I looked when I was considering doing one of my own and wanted to see an example. The Apache framework is pretty strong for putting in new directives, but not so much for adding new blocks. mma
Re: PerlOptions Clone/Parent in mp2
Marc M. Adkins wrote: wrt Apache 2.0, mod_perl 2.0... I'm not using Clone or Parent at the current time, but I was re-reading the documentation on them for an unrelated reason and started thinking about how they would work. Suppose I want to set up five virtual hosts with modules A - E. Then I want to set up six virtual hosts with modules F - M. The first five virtual hosts can all share a pool of interpreters and the second six virtual hosts can share a different pool of interpreters. How might I declare two parent interpreters globally, one with modules A - E and the other with modules F - M such that I could share a pool of interpreters derived from the first parent with five virtual hosts and a pool of interpreters derived the second parent with a different six virtual hosts? This is all theoretical, I don't actually need this right now, and probably won't ever. Just trying to imagine how these options would be used. Currently you can't do that. Each vhost can inherit from the base server perl, clone it or start a while new pool of interpreters. However I think it is possible to make the architecture more flexible to allow pools sharing across specific vhosts, or even location containers (if the scope is set to be only for the handler). e.g. something like: #base server # parameters # parameters PerlUseTiPool A PerlUseTiPool A PerlUseTiPool B PerlUseTiPool B Of course we are talking about threaded mpms here. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
