Re: Terminating Child process Dynamically

2012-03-07 Thread Perrin Harkins 
2012/3/7 Torsten Förtsch :
> Yes, in mp1 it did. Not so in mp2.

Oh, I see this was covered on the dev list.  It doesn't call
perl_destruct() because it may be running under threads, which mp1
didn't need to worry about.

- Perrin

Re: Apache::compat and new Perl

2012-03-07 Thread Fred Moyer 
On Wed, Mar 7, 2012 at 5:46 AM, Josh Narins  wrote:
>
> 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.

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.

Re: Funding [WAS :Re: trying to compile mod_perl against httpd-2.4.1]

2012-03-07 Thread Torsten Förtsch 
On Tuesday, 28 February 2012 18:14:20 Vincent Veyron wrote:
> I am a tiny one-man company using mod_perl with great success(*) and
> pleasure, and your post has me very worried that it could end in a
> hurry

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

Re: Terminating Child process Dynamically

2012-03-07 Thread Torsten Förtsch 
On Wednesday, 07 March 2012 08:06:37 Perrin Harkins wrote:
> It doesn't call perl_destruct()?  I thought it did in mod_perl 1

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

Apache::compat and new Perl

2012-03-07 Thread Josh Narins 
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
jnar...@seniorbridge.com
seniorbridge.com

[http://www.seniorbridge.com/images/seniorbridgedisclaimerTAG.gif]



SeniorBridge Statement of Confidentiality: The contents of this email message 
are intended for the exclusive use of the addressee(s) and may contain 
confidential or privileged information. Any dissemination, distribution or 
copying of this email by an unintended or mistaken recipient is strictly 
prohibited. In said event, kindly reply to the sender and destroy all entries 
of this message and any attachments from your system. Thank you.

Re: Terminating Child process Dynamically

2012-03-07 Thread Perrin Harkins 
[Sorry, that last message was sent by accident.  I set my phone to
require confirmation so it won't happen again.]

2012/3/7 Torsten Förtsch :
> 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

Re: Terminating Child process Dynamically

2012-03-07 Thread Perrin Harkins 
- Perrin
On Mar 7, 2012 7:00 AM, "Torsten Förtsch"  wrote:

> 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
>

Re: Terminating Child process Dynamically

2012-03-07 Thread Torsten Förtsch 
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