While I did find Torsten Förtsch's very useful Perl::AfterFork =20
module, surely the
mod_perl code must be doing something like this itself, no?
I'd be grateful to understand mod_perl's response to Perl's
pid caching is, given that forking *will* happen in the mod_perl
environment.
- Mark=
On Tue, Apr 15, 2008 at 8:51 AM, Mark Blackman
> While I did find Torsten Förtsch's very useful Perl::AfterFork module,
> surely the
> mod_perl code must be doing something like this itself, no?
I've been using fork, mod_perl, and $$ for years without a single
problem. Did you have some trouble that sent you looking for this
module?
- Perrin
On 15 Apr 2008, at 13:59, Perrin Harkins wrote:
> On Tue, Apr 15, 2008 at 8:51 AM, Mark Blackman
> wrote:
>> While I did find Torsten Förtsch's very useful Perl::AfterFork =20
>> module,
>> surely the
>> mod_perl code must be doing something like this itself, no?
>
> I've been using fork, mod_perl, and $$ for years without a single
> problem. Did you have some trouble that sent you looking for this
> module?
See http://www.jsw4.net/info/listserv_archives/mod_perl/07-wk25/ =20
msg00002.html
and
http://www.issociate.de/board/post/445529/=20
Process_ID_when_called_from_PerlChildInitHandler.html
And now I'm having trouble getting sense out of Apache::DProf because
$$ is wrong (and it's dumping all the child's output into the =20
parent's tmon.out)
My assumption is that perl caches the PID on startup and
only reinitializes on perl fork(), thus in the embedded case
a fork() outside the perl API doesn't reinitialize $$ at least
for some cases.
I'd love someone to explain why that's not the whole story, as
I'm sure it's not as this problem is clearly not global to all
mod_perl users.
- Mark
On Tue, Apr 15, 2008 at 9:05 AM, Mark Blackman
> My assumption is that perl caches the PID on startup and
> only reinitializes on perl fork(), thus in the embedded case
> a fork() outside the perl API doesn't reinitialize $$ at least
> for some cases.
It must be a mod_perl 2/apache 2 issue. I've never seen this happen
with mp1 or with perl programs that use fork().
- Perrin
On 15 Apr 2008, at 14:15, Perrin Harkins wrote:
> On Tue, Apr 15, 2008 at 9:05 AM, Mark Blackman
> wrote:
>> My assumption is that perl caches the PID on startup and
>> only reinitializes on perl fork(), thus in the embedded case
>> a fork() outside the perl API doesn't reinitialize $$ at least
>> for some cases.
>
> It must be a mod_perl 2/apache 2 issue. I've never seen this happen
> with mp1 or with perl programs that use fork().
well perl fork is clearly an obvious cache invalidation event.
in mod_perl 2.0.3 mod_perl.c, I can see..
static void modperl_hook_child_init(apr_pool_t *p, server_rec *s){
modperl_perl_init_ids_server(s);
and modperl_perl_init_ids_server() eventually calls
modperl_perl_init_ids() which itself eventually does a
sv_setiv(GvSV(gv_fetchpv("$", TRUE, SVt_PV)), ids->pid);
where ids->pid should contain the result of a recent getpid.
*However* I note that in the main perl code perl.c $$ is set
to be a readonly variable so I suspect, this code *might* need
to to look more like.
if ((tmpgv = gv_fetchpv("$",TRUE, SVt_PV))) {
SvREADONLY_off(GvSV(tmpgv));
sv_setiv(GvSV(tmpgv), ids->pid);
SvREADONLY_on(GvSV(tmpgv));
}
- Mark
>
> - Perrin
On Tue 15 Apr 2008, Mark Blackman wrote:
> While I did find Torsten Förtsch's very useful Perl::AfterFork =A0
> module, surely the
> mod_perl code must be doing something like this itself, no?
>
> I'd be grateful to understand mod_perl's response to Perl's
> pid caching is, given that forking *will* happen in the mod_perl
> environment.
There was/is a problem in mp1 that it did/does not reinitialize $$ and=20
getppid(). With mp2 I haven't seen this before.
But I have heard of pid caching inside C libraries. Maybe if you compile=20
modperl with another lib than apache. Then the apache lib caches and=20
reinitializes the pid in one place but modperl uses the other lib.
If you run linux you can have a look at /proc/PID/maps or /proc/pid/smaps. =
At=20
least shared libs are shown there.
Torsten
=2D-
Need professional mod_perl support?
Just ask me: torsten.foertsch@gmx.net
On 15 Apr 2008, at 16:00, Torsten Foertsch wrote:
> On Tue 15 Apr 2008, Mark Blackman wrote:
>> While I did find Torsten Förtsch's very useful Perl::AfterFork
>> module, surely the
>> mod_perl code must be doing something like this itself, no?
>>
>> I'd be grateful to understand mod_perl's response to Perl's
>> pid caching is, given that forking *will* happen in the mod_perl
>> environment.
>
> There was/is a problem in mp1 that it did/does not reinitialize $$ and
> getppid(). With mp2 I haven't seen this before.
>
> But I have heard of pid caching inside C libraries. Maybe if you =20
> compile
> modperl with another lib than apache. Then the apache lib caches and
> reinitializes the pid in one place but modperl uses the other lib.
Well this is a solaris 10 system and so it's just the straight /lib/=20
libc.so.1
in both cases.
I'd be surprised if this is the issue. I suppose I could knock up a =20
quick bit of
C to test it.
- Mark
>
> If you run linux you can have a look at /proc/PID/maps or /proc/pid/=20=
> smaps. At
> least shared libs are shown there.
>
> Torsten
>
> --
> Need professional mod_perl support?
> Just ask me: torsten.foertsch@gmx.net
On 15 Apr 2008, at 16:24, Mark Blackman wrote:
>
> On 15 Apr 2008, at 16:00, Torsten Foertsch wrote:
>> On Tue 15 Apr 2008, Mark Blackman wrote:
>>> While I did find Torsten Förtsch's very useful Perl::AfterFork
>>> module, surely the
>>> mod_perl code must be doing something like this itself, no?
>>>
>>> I'd be grateful to understand mod_perl's response to Perl's
>>> pid caching is, given that forking *will* happen in the mod_perl
>>> environment.
>>
>> There was/is a problem in mp1 that it did/does not reinitialize $$ =20=
>> and
>> getppid(). With mp2 I haven't seen this before.
>>
>> But I have heard of pid caching inside C libraries. Maybe if you =20
>> compile
>> modperl with another lib than apache. Then the apache lib caches and
>> reinitializes the pid in one place but modperl uses the other lib.
>
> Well this is a solaris 10 system and so it's just the straight /lib/=20=
> libc.so.1
> in both cases.
>
> I'd be surprised if this is the issue. I suppose I could knock up a =20=
> quick bit of
> C to test it.
#include
#include
#include
#include
int main(int argc, char *argv){
fork();
printf("my pid is %d\n",getpid());
}
which appears to demonstrate no caching of the pid of the system in =20
question.
- Mark
>
>
> - Mark
>
>>
>> If you run linux you can have a look at /proc/PID/maps or /proc/=20
>> pid/smaps. At
>> least shared libs are shown there.
>>
>> Torsten
>>
>> --
>> Need professional mod_perl support?
>> Just ask me: torsten.foertsch@gmx.net
>
On Tue, Apr 15, 2008 at 11:00 AM, Torsten Foertsch
> There was/is a problem in mp1 that it did/does not reinitialize $$ and
> getppid().
Under what circumstances? I use $$ all the time and have never seen
any sort of caching behavior from it. I use Linux.
- Perrin
On Tue 15 Apr 2008, Mark Blackman wrote:
> int main(int argc, char *argv){
> =A0 =A0fork();
> =A0 printf("my pid is %d\n",getpid());
> }
Please use the fork-syscall here not the C function.
Torsten=20
=2D-
Need professional mod_perl support?
Just ask me: torsten.foertsch@gmx.net
On 15 Apr 2008, at 17:27, Torsten Foertsch wrote:
> On Tue 15 Apr 2008, Mark Blackman wrote:
>> int main(int argc, char *argv){
>> fork();
>> printf("my pid is %d\n",getpid());
>> }
>
> Please use the fork-syscall here not the C function.
i'm trying to test the C-library behaviour though?
in my case, i got two different numbers, so that tells me there's
no caching surely.
- Mark
>
> Torsten
>
> --
> Need professional mod_perl support?
> Just ask me: torsten.foertsch@gmx.net
On Tue, Apr 15, 2008 at 8:28 AM, Mark Blackman
> modperl_perl_init_ids() which itself eventually does a
>
> sv_setiv(GvSV(gv_fetchpv("$", TRUE, SVt_PV)), ids->pid);
>
> where ids->pid should contain the result of a recent getpid.
>
> *However* I note that in the main perl code perl.c $$ is set
> to be a readonly variable so I suspect, this code *might* need
> to to look more like.
>
> if ((tmpgv = gv_fetchpv("$",TRUE, SVt_PV))) {
> SvREADONLY_off(GvSV(tmpgv));
> sv_setiv(GvSV(tmpgv), ids->pid);
> SvREADONLY_on(GvSV(tmpgv));
> }
>
> - Mark
one could replace the provided ${'$'} with a magic one that doesn't cache
I could write one with TIESCALAR and Inline::C but I think there are better
ways to do it and I don't want to clog up modperl list with first-draft code --
just ignore the cached PID by redefining $$'s FETCH accessor to wrap
get_pid() directly. So what if it will take another millisecond.
On 15 Apr 2008, at 17:27, Torsten Foertsch wrote:
> On Tue 15 Apr 2008, Mark Blackman wrote:
>> int main(int argc, char *argv){
>> fork();
>> printf("my pid is %d\n",getpid());
>> }
>
> Please use the fork-syscall here not the C function.
Right, the C library will almost certainly use
the fork() call here to invalidate and update the
cache entry. Using syscall(SYS_fork) guarantees
that the C library will not get a chance to update
its cache.
However, I'd be very surprised if any application (including
apache) deliberately used syscall(SYS_fork) over fork()
and so even if it is cached, the cache invalidation
is done at the right time.
- Mark
>
>
> Torsten
>
> --
> Need professional mod_perl support?
> Just ask me: torsten.foertsch@gmx.net
On 15 Apr 2008, at 13:51, Mark Blackman wrote:
> While I did find Torsten Förtsch's very useful Perl::AfterFork =20
> module, surely the
> mod_perl code must be doing something like this itself, no?
>
> I'd be grateful to understand mod_perl's response to Perl's
> pid caching is, given that forking *will* happen in the mod_perl
> environment.
Ok, more investigation suggests we're seeing an ordering problem.
mod_perl (2.0.3) does reinitialize $$ in
modperl_hook_child_init in mod_perl.c by calling
void modperl_perl_init_ids_server(server_rec *s) in modperl_perl.c
However, judicious sprinkling of printf statements suggests
very strongly that the above code gets called *AFTER* the
handler specified in PerlChildInitHandler.
Would anyone are to comment why the code above
would be done AFTER?
The routine names suggest that modperl_hook_child_init()
would get called before a PerlChildInitHandler to me, but
my logging suggests otherwise.
- Mark
>
>
> - Mark
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF8F031024EF2789375769511
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Mark Blackman wrote:
> On 15 Apr 2008, at 13:51, Mark Blackman wrote:
>=20
>> While I did find Torsten Förtsch's very useful Perl::AfterFork =20
>> module, surely the
>> mod_perl code must be doing something like this itself, no?
>>
>> I'd be grateful to understand mod_perl's response to Perl's
>> pid caching is, given that forking *will* happen in the mod_perl
>> environment.
>=20
> Ok, more investigation suggests we're seeing an ordering problem.
>=20
> mod_perl (2.0.3) does reinitialize $$ in
>=20
> modperl_hook_child_init in mod_perl.c by calling
>=20
> void modperl_perl_init_ids_server(server_rec *s) in modperl_perl.c
>=20
> However, judicious sprinkling of printf statements suggests
> very strongly that the above code gets called *AFTER* the
> handler specified in PerlChildInitHandler.
That's most likely correct. From src/modules/perl/mod_perl.c:
ap_hook_child_init(modperl_hook_child_init, [...]); /* Handler for $$ */
modperl_register_handler_hooks(); /* Handler for PerlCh=
ildInit */
So I assume the hook ordering for the same level is LIFO.
> Would anyone are to comment why the code above
> would be done AFTER?
It shouldn't be, IMO.
> The routine names suggest that modperl_hook_child_init()
> would get called before a PerlChildInitHandler to me, but
> my logging suggests otherwise.
Can you try this simple patch and see if it makes your troubles go away.
Index: src/modules/perl/mod_perl.c
==================== =====3D=
==================== =====3D=
=================3D
--- src/modules/perl/mod_perl.c (revision 643757)
+++ src/modules/perl/mod_perl.c (working copy)
@@ -896,7 +896,7 @@
NULL, NULL, MODPERL_HOOK_REALLY_REALLY_FIRST)=
;
ap_hook_child_init(modperl_hook_child_init,
- NULL, NULL, APR_HOOK_FIRST);
+ NULL, NULL, MODPERL_HOOK_REALLY_REALLY_FIRST);
modperl_register_handler_hooks();
}
--=20
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
--------------enigF8F031024EF2789375769511
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBa3WyzKhB4jDpaURAs4vAJ4lUSl2sl5McdVi0JwEVYUdDC47cACg tCMO
AZEZVQID/MPsh6OJPIIrMYo=
=di4s
-----END PGP SIGNATURE-----
--------------enigF8F031024EF2789375769511--
On 16 Apr 2008, at 08:42, Philippe M. Chiasson wrote:
>
> Can you try this simple patch and see if it makes your troubles go
> away.
It does indeed have the desired effect of getting $$ reset to the
child pid by the time the PerlChildInitHandler handler is called.
- Mark
>
>
> Index: src/modules/perl/mod_perl.c
> ============================================================ =======
> --- src/modules/perl/mod_perl.c (revision 643757)
> +++ src/modules/perl/mod_perl.c (working copy)
> @@ -896,7 +896,7 @@
> NULL, NULL,
> MODPERL_HOOK_REALLY_REALLY_FIRST);
>
> ap_hook_child_init(modperl_hook_child_init,
> - NULL, NULL, APR_HOOK_FIRST);
> + NULL, NULL, MODPERL_HOOK_REALLY_REALLY_FIRST);
>
> modperl_register_handler_hooks();
> }
>
>
> --
> Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107
> 88C3A5A5
> http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)
> \.org/
>
On 16 Apr 2008, at 10:24, Mark Blackman wrote:
>
> On 16 Apr 2008, at 08:42, Philippe M. Chiasson wrote:
>>
>> Can you try this simple patch and see if it makes your troubles go
>> away.
>
> It does indeed have the desired effect of getting $$ reset to the
> child pid by the time the PerlChildInitHandler handler is called.
I'm not quite sure what the positive result here suggests. Is that
patch appropriate as a long term fix? Should it be part of 2.0.4?
- Mark
>
> - Mark
>
>>
>>
>> Index: src/modules/perl/mod_perl.c
>> ============================================================ =======
>> --- src/modules/perl/mod_perl.c (revision 643757)
>> +++ src/modules/perl/mod_perl.c (working copy)
>> @@ -896,7 +896,7 @@
>> NULL, NULL,
>> MODPERL_HOOK_REALLY_REALLY_FIRST);
>>
>> ap_hook_child_init(modperl_hook_child_init,
>> - NULL, NULL, APR_HOOK_FIRST);
>> + NULL, NULL,
>> MODPERL_HOOK_REALLY_REALLY_FIRST);
>>
>> modperl_register_handler_hooks();
>> }
>>
>>
>> --
>> Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107
>> 88C3A5A5
>> http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)
>> \.org/
>>
>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig58239FAF5A9BDBC86E47D6BA
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Mark Blackman wrote:
> On 16 Apr 2008, at 10:24, Mark Blackman wrote:
>> On 16 Apr 2008, at 08:42, Philippe M. Chiasson wrote:
>>> Can you try this simple patch and see if it makes your troubles go =20
>>> away.
>> It does indeed have the desired effect of getting $$ reset to the
>> child pid by the time the PerlChildInitHandler handler is called.
Good, so it is clearly a bug then.
> I'm not quite sure what the positive result here suggests. Is that
> patch appropriate as a long term fix? Should it be part of 2.0.4?
It'll be part of 2.0.5, since 2.0.4 has just been released.
Any chance you could turn this bug into a patch to the test suite ?
--=20
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
--------------enig58239FAF5A9BDBC86E47D6BA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBvIxyzKhB4jDpaURApQPAJ9OyA5AyUKi5+756yP+HE2EBxyLfgCg nsnS
CQ4RonY3m/QP1NKN0l0LTMw=
=wNuQ
-----END PGP SIGNATURE-----
--------------enig58239FAF5A9BDBC86E47D6BA--
On 17 Apr 2008, at 07:46, Philippe M. Chiasson wrote:
> Mark Blackman wrote:
>> On 16 Apr 2008, at 10:24, Mark Blackman wrote:
>>> On 16 Apr 2008, at 08:42, Philippe M. Chiasson wrote:
>>>> Can you try this simple patch and see if it makes your troubles
>>>> go away.
>>> It does indeed have the desired effect of getting $$ reset to the
>>> child pid by the time the PerlChildInitHandler handler is called.
>
> Good, so it is clearly a bug then.
Right, so that's appropriate as a long term fix. I'll note that
on a very similar version of mod_perl/perl/apache on a linux
box, this problem doesn't crop up as though the hook calling
order works out differently there.
I couldn't for the life of me follow any details of the ap_hook_*
stuff.
>
>> I'm not quite sure what the positive result here suggests. Is that
>> patch appropriate as a long term fix? Should it be part of 2.0.4?
>
> It'll be part of 2.0.5, since 2.0.4 has just been released.
durn. what timing.
>
> Any chance you could turn this bug into a patch to the test suite ?
uhh. perhaps. I wonder how easy it will be to replicate on other
platforms.
- Mark
>
> --
> Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107
> 88C3A5A5
> http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)
> \.org/
>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3B53C5FB7A7BEDFA6C5665F7
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Mark Blackman wrote:
> On 17 Apr 2008, at 07:46, Philippe M. Chiasson wrote:
>> Mark Blackman wrote:
>>> On 16 Apr 2008, at 10:24, Mark Blackman wrote:
>>>> On 16 Apr 2008, at 08:42, Philippe M. Chiasson wrote:
>>>>> Can you try this simple patch and see if it makes your troubles =20
>>>>> go away.
>>>> It does indeed have the desired effect of getting $$ reset to the
>>>> child pid by the time the PerlChildInitHandler handler is called.
>> Good, so it is clearly a bug then.
>=20
> Right, so that's appropriate as a long term fix. I'll note that
> on a very similar version of mod_perl/perl/apache on a linux
> box, this problem doesn't crop up as though the hook calling
> order works out differently there.
>=20
> I couldn't for the life of me follow any details of the ap_hook_*
> stuff.
>=20
>>> I'm not quite sure what the positive result here suggests. Is that
>>> patch appropriate as a long term fix? Should it be part of 2.0.4?
>> It'll be part of 2.0.5, since 2.0.4 has just been released.
>=20
> durn. what timing.
Committed revision 649412.
It's going to be in 2.0.5
--=20
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
--------------enig3B53C5FB7A7BEDFA6C5665F7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFICGFlyzKhB4jDpaURApMyAJjVC8FDPDA4zrS5bIlru9nVKph7AJ9h sNWb
n8/mVXEXSDCpuZj5F8/+mQ==
=jdOw
-----END PGP SIGNATURE-----
--------------enig3B53C5FB7A7BEDFA6C5665F7--
On 18 Apr 2008, at 09:52, Philippe M. Chiasson wrote:
> Mark Blackman wrote:
>> On 17 Apr 2008, at 07:46, Philippe M. Chiasson wrote:
>>> Mark Blackman wrote:
>>>> On 16 Apr 2008, at 10:24, Mark Blackman wrote:
>>>>> On 16 Apr 2008, at 08:42, Philippe M. Chiasson wrote:
>>>>>> Can you try this simple patch and see if it makes your
>>>>>> troubles go away.
>>>>> It does indeed have the desired effect of getting $$ reset to the
>>>>> child pid by the time the PerlChildInitHandler handler is called.
>>> Good, so it is clearly a bug then.
>> Right, so that's appropriate as a long term fix. I'll note that
>> on a very similar version of mod_perl/perl/apache on a linux
>> box, this problem doesn't crop up as though the hook calling
>> order works out differently there.
>> I couldn't for the life of me follow any details of the ap_hook_*
>> stuff.
>>>> I'm not quite sure what the positive result here suggests. Is that
>>>> patch appropriate as a long term fix? Should it be part of 2.0.4?
>>> It'll be part of 2.0.5, since 2.0.4 has just been released.
>> durn. what timing.
>
> Committed revision 649412.
>
> It's going to be in 2.0.5
Great! thanks. Will see what kind of testing I can set up.
- Mark
>
> --
> Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107
> 88C3A5A5
> http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)
> \.org/
>