You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/12/12 22:39:53 UTC
DSOs and the once_through logic in some 2.0 modules
In short: It's broke.
Several modules in 2.0 have a flag called once_through which they use
to perform certain processing only on the second call to their post
config hook. They expect that after incrementing it on the first call
that it will be greater than zero on the second call. This isn't true
with DSOs because the second call is for a new instance of the DSO so
the once_through flag is zero again. (Yes, this would have failed in
1.3 also; I just verified that.)
The modules:
mod_rewrite (logic added in the initial port to 2.0 for
unspecified reasons)
mod_cgid (new module)
mod_file_cache (new module)
Does anybody consider it crucial to do stuff only on the last call?
If so, we can invent a way that always works.
Obviously we can avoid some expensive stuff (like processes created in
mod_rewrite only to be killed off immediately) if we only do it on the
last call; OTOH, doing everything twice helps test our pool cleanup
logic.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: DSOs and the once_through logic in some 2.0 modules
Posted by Jeff Trawick <tr...@bellsouth.net>.
"Paul J. Reder" <re...@raleigh.ibm.com> writes:
> Jeff Trawick wrote:
> > mod_rewrite (logic added in the initial port to 2.0 for
> > unspecified reasons)
> > Obviously we can avoid some expensive stuff (like processes created in
> > mod_rewrite only to be killed off immediately) if we only do it on the
> > last call; OTOH, doing everything twice helps test our pool cleanup
> > logic.
>
> You are correct in your guess that mod_rewrite used the logic to avoid
> starting multiple external rewriting programs. You are also right that
> the first incarnation should get cleaned up for DSOs. I experienced problems
> trying to start two instances of the external program when it was statically
> linked. Hence the code to only start it on the second pass.
There may be/have been a problem cleaning up the processes when the
first pool went away... dunno
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: DSOs and the once_through logic in some 2.0 modules
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Jeff Trawick wrote:
> mod_rewrite (logic added in the initial port to 2.0 for
> unspecified reasons)
> Obviously we can avoid some expensive stuff (like processes created in
> mod_rewrite only to be killed off immediately) if we only do it on the
> last call; OTOH, doing everything twice helps test our pool cleanup
> logic.
You are correct in your guess that mod_rewrite used the logic to avoid
starting multiple external rewriting programs. You are also right that
the first incarnation should get cleaned up for DSOs. I experienced problems
trying to start two instances of the external program when it was statically
linked. Hence the code to only start it on the second pass.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: DSOs and the once_through logic in some 2.0 modules
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > Obviously we can avoid some expensive stuff (like processes created in
> > mod_rewrite only to be killed off immediately) if we only do it on the
> > last call; OTOH, doing everything twice helps test our pool cleanup
> > logic.
>
> There are actually a couple of times that we really do want to only do
> something once. The best way IMHO to do this, is to save some user-data
> in the process_rec's pool variable. This pool is garaunteed to be
> available after the pool cleanup's, and it mirrors what Ralf did with
> EAPI, so we know it will work for SSL.
sounds cool... I'll take care of it.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: DSOs and the once_through logic in some 2.0 modules
Posted by rb...@covalent.net.
> Several modules in 2.0 have a flag called once_through which they use
> to perform certain processing only on the second call to their post
> config hook. They expect that after incrementing it on the first call
> that it will be greater than zero on the second call. This isn't true
> with DSOs because the second call is for a new instance of the DSO so
> the once_through flag is zero again. (Yes, this would have failed in
> 1.3 also; I just verified that.)
>
> The modules:
>
> mod_rewrite (logic added in the initial port to 2.0 for
> unspecified reasons)
> mod_cgid (new module)
> mod_file_cache (new module)
>
> Does anybody consider it crucial to do stuff only on the last call?
> If so, we can invent a way that always works.
>
> Obviously we can avoid some expensive stuff (like processes created in
> mod_rewrite only to be killed off immediately) if we only do it on the
> last call; OTOH, doing everything twice helps test our pool cleanup
> logic.
There are actually a couple of times that we really do want to only do
something once. The best way IMHO to do this, is to save some user-data
in the process_rec's pool variable. This pool is garaunteed to be
available after the pool cleanup's, and it mirrors what Ralf did with
EAPI, so we know it will work for SSL.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------