You should be fine without mp1, but remember you'll need to build it
against another httpd with your different perl. You can't build
mod_perl against the same httpd that already has one built or it will
replace that module you've built against the original perl.
So am I and so are many (perhaps most) of the other contributors. What I am
trying to say is, if modperl is the basis of your business why don't you start
contribute? You'll be in good and friendly company.
This is how I got to modperl. In the late 1990ies I did a project involving
mp1. That was almost my first encounter with Perl. A few years later that
client wanted to switch to httpd 2.0. So, they hired me again. At that time I
had a few years of experience in Perl. I also had skimmed through
perlxs/guts/api but was far from understanding it. I had tried a few examples
but that was all.
One of the first things I did for modperl was a fix for APR::Base64.I had
noticed that one of encode() or decode() left a superfluous \0 byte at the end
of the resulting string. Of course I could switch to MIME::Base64 and forget
about APR::Base64. But that would mean to dupliate the code to work with
base64 encoding - something I don't like at all. So, I tried to fix the bug
and surprisingly succeeded. It wasn't by far as complicated as I had expected.
In the end the patch I sent to the mailing list didn't get applied as I had
sent it, I think (but maybe this was another patch). Someone more experienced
had found a better solution.
At that time I had reported to my client that mp2 works. I also had read the
docs and was intrigued by "PerlInterpScope handler". I had asked on the users
list if it was a good idea to use it and was encouraged by Stas to go ahead.
Well, it was disastrous and I ended up hacking modperl_interp.c. I think I
have found and fixed a few bugs. And - much more important - I have learned a
big deal about httpd, modperl and perl. Also, before that time I seldom
reported bugs or wrote to mailing lists. I was too shy - my command of English
was embarrassing.
Also, it occurred to me that the creators of all of these shining open source
programs are not god-like creatures but people like you and me. And if I want
these projects to succeed I have to contribute my share.
I didn't want to worry you. Quite the contrary, I wanted to encourage people
to join. Give it time and modperl will support httpd 2.4. But it requires work
to be done. You can help.
Sorry for the late reply, I was on vacation.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Yes, in mp1 it did. Not so in mp2.
static apr_status_t child_terminate(void *data) {
apr_pool_t *pool = (apr_pool_t *)data;
/* On the first pass, re-register so we end up last */
if (data) {
apr_pool_cleanup_register(pool, NULL, child_terminate,
apr_pool_cleanup_null);
}
else {
exit(0);
}
return APR_SUCCESS;
}
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Do I need mod_perl1 installed to get Apache::compat and mod_perl2 to work?
mp2 will be using a different Perl, and I'd prefer not to install it if I don't have to.
Josh Narins
Director of Application Development
SeniorBridge
845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Fax: (212) 994-4260
Mobile: (917) 488-6248
jnarins@seniorbridge.com
seniorbridge.com
2012/3/7 Torsten Förtsch <torsten.foertsch@gmx.net>:
> 2) the way child_terminate() exits is quite nasty because it simply calls
> exit() at C level. That means neither END blocks nor PerlChildExitHandlers are
> executed nor are static perl objects destroyed.
It doesn't call perl_destruct()? I thought it did in mod_perl 1:
http://perl.apache.org/docs/general/control/control.html#Speeding_up_the_Apache_Termination_and_Restart
- Perrin
- Perrin
On Friday, 02 March 2012 13:49:34 Perrin Harkins wrote:
> You can use $r-->child_terminate().
2 remarks:
1) you can use this method at any point in the request cycle. It marks the
process to be terminated when the current request is done.
2) the way child_terminate() exits is quite nasty because it simply calls
exit() at C level. That means neither END blocks nor PerlChildExitHandlers are
executed nor are static perl objects destroyed.
Perhaps a more perlish way to terminate the current process is
{
package My::Terminator;
sub DESTROY {CORE::exit 0}
sub new {return bless \my $dummy, __PACKAGE__}
}
$r->pnotes->{terminator}=My::Terminator->new;
Thus, global Perl objects will be destroyed properly and the process exits
when the current request is done.
If you are already using some kind of scope guard module (e.g. Guard) you can
achieve the same even simpler:
$r->pnotes->{terminator}=guard {CORE::exit 0};
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
2 remarks:
1) you can use this method at any point in the request cycle. It marks the
process to be terminated when the current request is done.
2) the way child_terminate() exits is quite nasty because it simply calls
exit() at C level. That means neither END blocks nor PerlChildExitHandlers are
executed nor are static perl objects destroyed.
Perhaps a more perlish way to terminate the current process is
{
package My::Terminator;
sub DESTROY {CORE::exit 0}
sub new {return bless \my $dummy, __PACKAGE__}
}
$r->pnotes->{terminator}=My::Terminator->new;
Thus, global Perl objects will be destroyed properly and the process exits
when the current request is done.
If you are already using some kind of scope guard module (e.g. Guard) you can
achieve the same even simpler:
$r->pnotes->{terminator}=guard {CORE::exit 0};
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Posts
