You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Dave Rolsky <au...@urth.org> on 2006/06/16 16:49:02 UTC
Releasing an independent Apache::SizeLimit to CPAN?
Apache::SizeLimit has a long-standing bug on Linux where it never actually
kills a child, because of Perl's caching of ppid info internally, and the
way this interacts with Apache's forking.
See this thread for details:
http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EEFE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
At $DAYJOB, we have a hacked version that works around this problem. I'd
like to release a version with a less hack-y fix to CPAN so we can stop
maintaining a forked version in-house.
Are there any objections to me doing this? I'd need someone with
maintainer privs for mod_perl1 to give me co-maintainership of that module
for it to get indexed, obviously.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 16 Jun 2006, Dave Rolsky wrote:
> But I wasn't saying "I'm going to release it, screw you." I was saying "I'd
> like to release a bug-fixed version, because I have no idea when mod_perl
> 1.30 will come out, if ever, but I can fix this bug and release
> Apache::SizeLimit 0.04 right now."
I should also note that part of the whole dual-lifing thing is that the
person who maintains the CPAN version provides patches back to p5p. In
this case, I could provide a patch for mod_perl1 if there is any plans to
actually release another version of it.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I apologize. Note the question mark in the title of this thread. I
> thought I was offering to help the mod_perl project, honestly.
my last comment was meant to be an understanding as well, but it didn't
come off that way. sorry. if we didn't know eachother in person then I
might have spent more time trying to iron out the wrinkles in everything
I write...
so, ok, we're cool. I'll buy you some thai in portland. moving on :)
--Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 16 Jun 2006, Geoffrey Young wrote:
>> But I wasn't saying "I'm going to release it, screw you."
>
> sure sounded that way, but ok.
I apologize. Note the question mark in the title of this thread. I thought
I was offering to help the mod_perl project, honestly.
>> I was saying "I'd like to release a bug-fixed version, because I have
>> no idea when mod_perl 1.30 will come out, if ever, but I can fix this
>> bug and release Apache::SizeLimit 0.04 right now."
>
> still, you think that would fly on p5p? the change list on mp1 is very
Yes, it would fly on p5p. I did it with Time::Local, for example. In fact,
p5p is very much in favor of dual-lifing modules, from what I can tell.
Making something dual-life from the Perl core is relatively matter-of-fact
these days. Heck, even very "internal-y" things like Threads.pm have been
dual-lifed.
> small, which is why there hasn't been a release in a while. and you're
> certainly capable of posting a patch and using CVS instead of
> maintaining a separate fork.
The reason I want to release this is because we use Apache::SizeLimit at
my day job. We're planning to open source our code eventually, and we
don't want to release a forked Apache::SizeLimit, obviously. That means
either getting a fixed version on CPAN or renaming our version to
Socialtext::Apache::SizeLimit. I think the former is better since it
benefits all mod_perl 1.x users.
Waiting for mod_perl 1.30 is really not an option. We can't have much
impact over when that will come out, and I don't think we'd want to make
that a prereq anyway. 1.29 is 2.5 years old, so pretty much every modern
distro has it available as package. 1.30, even if it came out tomorrow,
would be too new to make a prereq.
Telling people who go to install our app that they need to install
Apache::SizeLimit "plus some random patch" on our servers would be pretty
user-unfriendly. That's not how you make a nice install process for folks.
We want to say "you need mod_perl 1.29" plus Apache::SizeLimit 0.04, and
have them be able to get that stuff via packages and/or CPAN, just like
everything else.
> separation is, in fact, a good thing, whether we want to pull in the
> CPAN version on future releases, or drop it and confuse our userbase who
> thought they would be getting an update on the next release, etc.
Like I said, I'd be happy to provide patches back to the mod_perl folks
against what's in your tree. If a 1.30 is planned, I'd work with the
maintainer to make sure that Apache::SizeLimit in the tree was up to date
with what's on CPAN.
Frankly, I'm kind of insulted you'd think I'd make this a lot of work for
the maintainer. I think I have a pretty good history of being a good free
software citizen, especially in the Perl and mod_perl worlds. Please give
me some credit here.
> so, to that end, I'd suggest starting up a "hey, what do we do with
> Apache::SizeLimit and other modules that might benefit from a separate
> life on CPAN?" personally, it doesn't matter to me what the outcome is
No, let's not start that thread, please. I'm not proposing to maintain any
other modules, and I don't want to have an Apache::SizeLimit release gate
on a decision about every other module. I'm proposing something small,
simple, and doable in a short time frame.
If I do this and it inspires other people to come along and dual-life
something else, that'd be great, I think.
> so long as the main people responsible for managing releases agree. one
> thing for sure, though, I'd really prefer to see both mp1 and mp2
> supported in a single release if Apache::SizeLimit does have a new,
> separate life on CPAN...
What Philip said ;)
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Perrin Harkins <pe...@elem.com>.
Philip M. Gollucci wrote:
> At least according to the docs Stas wrote, I think he was hoping
> Apache::GtopLimit would obsolete
> Apache(2)::SizeLimit once it ran on enough architectures.
I think the current reality is that GTop is not very easy to compile on
many architectures, and the pure-perl nature of SizeLimit makes it
easier for users to contribute patches to. I don't see it going away.
- Perrin
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Geoffrey Young wrote:
> let's just get them working together in the same distribution, put in on
> cpan, and pull it into each mod_perl release as they happen...
+1 here.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Philip M. Gollucci wrote:
>> supported in a single release if Apache::SizeLimit does have a new,
>> separate life on CPAN...
>
> I'm not sure thats easily possibly with one module because its
> Apache::SizeLimit
> AND Apache2::SizeLimit.
so. it's just a namespace - Apache2::SizeLimit could simply be a thin
wrapper around Apache::SizeLimit, throwing a nice critical log message
to change to the real Apache::SizeLimit, please.
>
> If you put Apache::SizeLimit on CPAN which supported both, we'd probably
> have to remove the one
> from modperl2-svn and any existing modperl 2 installations would need to
> go back
> and change there httpd.conf/startup.pl to use it again.
there are ways around that that won't hurt so bad, like the above.
>
> By doing so, that would be directly the opposite of what our API rename
> readme said to do.
that's fine. _someone_ is going to have to change, be it mp1 or mp2
users if we roll this out to CPAN. or we will, by including a cpan pull
when we roll a release.
>
> I'd actually rather just see mod_perl1.30 get released. So what if the
> change set it small
> it should really only be bugfix/security anyway at this point. So what
> if 1.31 only has 1 change
> over 1.30. Isn't that how "maintenance" releases work best ?
I wasn't against a release. I was just saying there's a reason it
hasn't been released lately :)
>
> At least according to the docs Stas wrote, I think he was hoping
> Apache::GtopLimit would obsolete
> Apache(2)::SizeLimit once it ran on enough architectures.
well, first things first :)
look, if we release Apache::SizeLimit to cpan then we're essentially
giving up control of it in mod_perl core. that's fine, so long as we
let users know. but I'm bothered that we'd have something on CPAN that
is 99% the same between mp1 and mp2, leaving us core maintainers with
extra work keeping them in sync, which is much harder when one is
outside our control and in the CPAN wild.
let's just get them working together in the same distribution, put in on
cpan, and pull it into each mod_perl release as they happen...
--Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
> supported in a single release if Apache::SizeLimit does have a new,
> separate life on CPAN...
I'm not sure thats easily possibly with one module because its Apache::SizeLimit
AND Apache2::SizeLimit.
If you put Apache::SizeLimit on CPAN which supported both, we'd probably have to remove the one
from modperl2-svn and any existing modperl 2 installations would need to go back
and change there httpd.conf/startup.pl to use it again.
By doing so, that would be directly the opposite of what our API rename readme said to do.
I'd actually rather just see mod_perl1.30 get released. So what if the change set it small
it should really only be bugfix/security anyway at this point. So what if 1.31 only has 1 change
over 1.30. Isn't that how "maintenance" releases work best ?
At least according to the docs Stas wrote, I think he was hoping Apache::GtopLimit would obsolete
Apache(2)::SizeLimit once it ran on enough architectures.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by David Wheeler <da...@kineticode.com>.
On Jun 20, 2006, at 09:06, Geoffrey Young wrote:
> o whether Apache::SizeLimit should support both mp1 and mp2
Yes.
> o whether future releases of mp1 and mp2 will include
> Apache::SizeLimit
Don't care.
> o whether the mod_perl project should continue to have oversight via
> svn (for example, make Apache-SizeLimit a separate repository and
> granting dave karma) or whether we're handing the code off completely
> (to be hosted going forward in dave's realm)
I think keeping it in the mod_perl project svn is a good idea.
Just my $0.02 (not worth what it used to be, given the poor value of
the dollar).
Best,
David
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Tue, 20 Jun 2006, Geoffrey Young wrote:
> I think I'd really like to see several things decided via public discussion:
>
> o whether Apache::SizeLimit should support both mp1 and mp2
Eventually, that'd be fine. I don't want that to be a barrier for an
initial independent release.
> o whether future releases of mp1 and mp2 will include Apache::SizeLimit
Whatever the maintainers of those projects want is fine with me.
> the simplest solution to this is probably keeping the code at
> svn.apache.org, granting dave the appropriate karma, and allow him to
> act as release manager for Apache-SizeLimit. once that's complete, I
> have a feeling the other concerns will fall into place in typical public
> forum style.
Sure, that works for me. Do I need to sign something? If so, could we take
care of that at YAPC?
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Supporting both APIs _and_ sending patches to the dev list seems
> contradictory. If I made a version that supported both APIs, I wouldn't
> expect that version to end up in a future mod_perl 1 or 2 release.
not exactly related, but are we really talking about a full-scale
handoff? it seems odd to me to take part of what we've considered core
and completely hand it off to a third-party, then rolling it back into
future releases, all without current developer involvement.
I think I'd really like to see several things decided via public discussion:
o whether Apache::SizeLimit should support both mp1 and mp2
o whether future releases of mp1 and mp2 will include Apache::SizeLimit
o whether the mod_perl project should continue to have oversight via
svn (for example, make Apache-SizeLimit a separate repository and
granting dave karma) or whether we're handing the code off completely
(to be hosted going forward in dave's realm)
I think the last bullet is important to consider, especially from an
ASF-licensing pov - if the project completely relinquishes control then
for each inclusion in future releases we'd need to vet whether the new
code maintains the ASF license and didn't break it along the way. yeah,
I know, and I hate that we need to think of things like that, but the
code belongs to the ASF so...
the simplest solution to this is probably keeping the code at
svn.apache.org, granting dave the appropriate karma, and allow him to
act as release manager for Apache-SizeLimit. once that's complete, I
have a feeling the other concerns will fall into place in typical public
forum style.
--Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Sat, 17 Jun 2006, Perrin Harkins wrote:
> For the record, I'm thrilled to have Dave's help with this module. I
> was doing most of the work on it in the past, but have not been keeping
> up with it. I kind of lost my zeal for it when we discovered how wrong
> the copy-on-write sharing numbers were.
It looks like Apache2::SizeLimit fixes though, right? I think integrating
that work into Apache::SizeLimit is a good idea.
> Separating it out seems fine to me. I'd vote for simply dropping it from the
> mod_perl distribution if we do that, but if people want to keep it there, I'm
> okay with that too. Supporting both mod_perl APIs and sending patches to the
> dev list would be great if we plan to keep it in.
Supporting both APIs _and_ sending patches to the dev list seems
contradictory. If I made a version that supported both APIs, I wouldn't
expect that version to end up in a future mod_perl 1 or 2 release.
OTOH, if I just clean up Apache::SizeLimit and we leave Apache2::SizeLimit
alone then sending patches so it can be included in mod_perl 1.30+ makes
sense.
If you want to remove it from the distro that's fine with me too.
> I'll be off e-mail for a few days, but will check in on this when I get back.
> Maybe we can discuss in person if you guys will be at YAPC.
I will be there, but looks like Geoff won't be. Let's plan to chat about
this while we're there.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
> except that it is. so you're asking to change that. fine, but it needs
> to be decided on by the maintainers (mainly perrin) whether this
> separation is, in fact, a good thing, whether we want to pull in the
> CPAN version on future releases, or drop it and confuse our userbase who
> thought they would be getting an update on the next release, etc.
For the record, I'm thrilled to have Dave's help with this module. I
was doing most of the work on it in the past, but have not been keeping
up with it. I kind of lost my zeal for it when we discovered how wrong
the copy-on-write sharing numbers were.
Separating it out seems fine to me. I'd vote for simply dropping it
from the mod_perl distribution if we do that, but if people want to keep
it there, I'm okay with that too. Supporting both mod_perl APIs and
sending patches to the dev list would be great if we plan to keep it in.
I'll be off e-mail for a few days, but will check in on this when I get
back. Maybe we can discuss in person if you guys will be at YAPC.
- Perrin
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>> Are there any objections to me doing this?
>>
>>
>> uh, yeah. how about you submit the patch here and we incorporate it?
>> just uploading modules to CPAN that collide with the namespace of
>> existing modules that are part of a distrubution isn't the way things
>> typically work. I mean, you wouldn't ask this of p5p for a module like,
>> say, Storable, would you?
>
>
> Yes, I would. In fact, Storable _is_ on CPAN separate from the Perl core
> _right now_, and has been for a really long time. It's called
> "dual-lifing" a module in p5p-speak.
yeah, I know all about those. I just chose a poor example. pick any
non-dual one you like, the principle is the same.
>
> But I wasn't saying "I'm going to release it, screw you."
sure sounded that way, but ok.
> I was saying
> "I'd like to release a bug-fixed version, because I have no idea when
> mod_perl 1.30 will come out, if ever, but I can fix this bug and release
> Apache::SizeLimit 0.04 right now."
still, you think that would fly on p5p? the change list on mp1 is very
small, which is why there hasn't been a release in a while. and you're
certainly capable of posting a patch and using CVS instead of
maintaining a separate fork.
> There's no good reason for Apache::SizeLimit to only be available as
> part of the whole big mod_perl bundle.
except that it is. so you're asking to change that. fine, but it needs
to be decided on by the maintainers (mainly perrin) whether this
separation is, in fact, a good thing, whether we want to pull in the
CPAN version on future releases, or drop it and confuse our userbase who
thought they would be getting an update on the next release, etc.
> It's basically "just another
> handler" like many other modules and CPAN, and having it be possible to
> update it separately from mod_perl is a _good_ thing.
perhaps.
> It de-couples two
> things which are only coupled for historical reasons.
sure. but like I said, it's just a bit more complex when you consider
what this will mean for users and the complexity of future mod_perl
releases.
so, to that end, I'd suggest starting up a "hey, what do we do with
Apache::SizeLimit and other modules that might benefit from a separate
life on CPAN?" personally, it doesn't matter to me what the outcome is
so long as the main people responsible for managing releases agree. one
thing for sure, though, I'd really prefer to see both mp1 and mp2
supported in a single release if Apache::SizeLimit does have a new,
separate life on CPAN...
--Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 16 Jun 2006, Geoffrey Young wrote:
> Dave Rolsky wrote:
>> Apache::SizeLimit has a long-standing bug on Linux where it never
>> actually kills a child, because of Perl's caching of ppid info
>> internally, and the way this interacts with Apache's forking.
>>
>> See this thread for details:
>> http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EEFE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
>>
>>
>> At $DAYJOB, we have a hacked version that works around this problem. I'd
>> like to release a version with a less hack-y fix to CPAN so we can stop
>> maintaining a forked version in-house.
>>
>> Are there any objections to me doing this?
>
> uh, yeah. how about you submit the patch here and we incorporate it?
> just uploading modules to CPAN that collide with the namespace of
> existing modules that are part of a distrubution isn't the way things
> typically work. I mean, you wouldn't ask this of p5p for a module like,
> say, Storable, would you?
Yes, I would. In fact, Storable _is_ on CPAN separate from the Perl core
_right now_, and has been for a really long time. It's called
"dual-lifing" a module in p5p-speak.
But I wasn't saying "I'm going to release it, screw you." I was saying
"I'd like to release a bug-fixed version, because I have no idea when
mod_perl 1.30 will come out, if ever, but I can fix this bug and release
Apache::SizeLimit 0.04 right now."
There's no good reason for Apache::SizeLimit to only be available as part
of the whole big mod_perl bundle. It's basically "just another handler"
like many other modules and CPAN, and having it be possible to update it
separately from mod_perl is a _good_ thing. It de-couples two things which
are only coupled for historical reasons.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Dave Rolsky wrote:
> Apache::SizeLimit has a long-standing bug on Linux where it never
> actually kills a child, because of Perl's caching of ppid info
> internally, and the way this interacts with Apache's forking.
>
> See this thread for details:
> http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EEFE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
>
>
> At $DAYJOB, we have a hacked version that works around this problem. I'd
> like to release a version with a less hack-y fix to CPAN so we can stop
> maintaining a forked version in-house.
>
> Are there any objections to me doing this?
uh, yeah. how about you submit the patch here and we incorporate it?
just uploading modules to CPAN that collide with the namespace of
existing modules that are part of a distrubution isn't the way things
typically work. I mean, you wouldn't ask this of p5p for a module like,
say, Storable, would you?
--Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 16 Jun 2006, Perrin Harkins wrote:
> Dave Rolsky wrote:
>> Apache::SizeLimit has a long-standing bug on Linux where it never actually
>> kills a child, because of Perl's caching of ppid info internally, and the
>> way this interacts with Apache's forking.
>>
>> See this thread for details:
>> http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EEFE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
>
> You're saying that it always thinks it is in the main process even though
> it's actually in a child? I haven't seen this behavior. Is it specific to
> certain versions of Perl or Linux?
We saw this with Perl 5.8.4 on Ubuntu Hoary. I think it's specific to
Linux from reading the thread. My plan was to just use Linux::Pid on Linux
systems, because from my testing it's version of getppid does the right
thing.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Torsten Foertsch wrote:
> On Friday 16 June 2006 19:19, Dave Rolsky wrote:
>
>>Requiring syscall.ph seems like a nasty hack to me. That _is_ what we've
>>done with our local version here at Socialtext, but I was planning to use
>>Linux::Pid for a CPAN version, since it seems cleaners.
>
>
> No, I meant the Perl::AfterFork ChildInitHandler:
>
> http://www.gossamer-threads.com/lists/modperl/modperl/82057#82057
>
> But anyway, if you are going to patch Apache::SizeLimit using Linux::Pid would
> be better. On the other hand the best solution would be to patch mod_perl and
> to incorporate the stuff from mp2 since other modules may also suffer from
> the cache.
yeah, I think that really need to be the case - if we're going to spin
off Apache::SizeLimit (which at this point sounds like a decent idea) we
really need to reduce our workload and make sure it works on both mp1
and mp2.
separately from that, if it gets a life of its own we'll need to decide
whether we continue to include Apache::SizeLimit in mp1 and mp2
distributions (in which case we'll need to adjust our release procedure
to pull it, etc) or whether we're going to document that it now lives
elsewhere...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Torsten Foertsch <to...@gmx.net>.
On Friday 16 June 2006 19:19, Dave Rolsky wrote:
> Requiring syscall.ph seems like a nasty hack to me. That _is_ what we've
> done with our local version here at Socialtext, but I was planning to use
> Linux::Pid for a CPAN version, since it seems cleaners.
No, I meant the Perl::AfterFork ChildInitHandler:
http://www.gossamer-threads.com/lists/modperl/modperl/82057#82057
But anyway, if you are going to patch Apache::SizeLimit using Linux::Pid would
be better. On the other hand the best solution would be to patch mod_perl and
to incorporate the stuff from mp2 since other modules may also suffer from
the cache.
Torsten
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 16 Jun 2006, Torsten Foertsch wrote:
> Yes, since 5.8.1. The problem is that the now old linux-threads implementation
> returns different values for getpid() and getppid() for different threads.
> Hence Perl decides better to cache these values and update the cache on
> fork() to make it more compatible with other thread implementations. Since
> Apache does its own fork the cache is not updated. Mp2 contains code that
> handles the situation but mp1 does not.
>
> For more information see also
>
> http://www.gossamer-threads.com/lists/perl/porters/193162
> http://www.gossamer-threads.com/lists/perl/porters/175806
>
> Dave, have you tried the proposed approach from the thread you mentioned?
Requiring syscall.ph seems like a nasty hack to me. That _is_ what we've
done with our local version here at Socialtext, but I was planning to use
Linux::Pid for a CPAN version, since it seems cleaners.
> If you are working on Apache::SizeLimit maybe you could incorporate also
> Linux::Smaps for newer kernels. Also the problem of counting out of core
> pages could be addressed at least in the docs, see
>
> http://www.gossamer-threads.com/lists/modperl/dev/84375
Yeah, I noticed that Apache2::SizeLimit had a bunch of changes. I was
thinking I could incorporate those too.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Torsten Foertsch <to...@gmx.net>.
On Friday 16 June 2006 17:23, Perrin Harkins wrote:
> Dave Rolsky wrote:
> > Apache::SizeLimit has a long-standing bug on Linux where it never
> > actually kills a child, because of Perl's caching of ppid info
> > internally, and the way this interacts with Apache's forking.
> >
> > See this thread for details:
> > http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EE
> >FE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
>
> You're saying that it always thinks it is in the main process even
> though it's actually in a child? I haven't seen this behavior. Is it
> specific to certain versions of Perl or Linux?
Yes, since 5.8.1. The problem is that the now old linux-threads implementation
returns different values for getpid() and getppid() for different threads.
Hence Perl decides better to cache these values and update the cache on
fork() to make it more compatible with other thread implementations. Since
Apache does its own fork the cache is not updated. Mp2 contains code that
handles the situation but mp1 does not.
For more information see also
http://www.gossamer-threads.com/lists/perl/porters/193162
http://www.gossamer-threads.com/lists/perl/porters/175806
Dave, have you tried the proposed approach from the thread you mentioned?
> PerlModule Perl::AfterFork
> PerlModule Apache::Constants
> PerlInitHandler "sub {Perl::AfterFork::reinit(); return Apache::OK;}"
>
> or
>
> PerlModule Perl::AfterFork
> PerlInitHandler "sub {Perl::AfterFork::reinit();}"
If you are working on Apache::SizeLimit maybe you could incorporate also
Linux::Smaps for newer kernels. Also the problem of counting out of core
pages could be addressed at least in the docs, see
http://www.gossamer-threads.com/lists/modperl/dev/84375
Torsten
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Torsten Foertsch <to...@gmx.net>.
On Friday 16 June 2006 17:23, Perrin Harkins wrote:
> Dave Rolsky wrote:
> > Apache::SizeLimit has a long-standing bug on Linux where it never
> > actually kills a child, because of Perl's caching of ppid info
> > internally, and the way this interacts with Apache's forking.
> >
> > See this thread for details:
> > http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EE
> >FE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
>
> You're saying that it always thinks it is in the main process even
> though it's actually in a child? I haven't seen this behavior. Is it
> specific to certain versions of Perl or Linux?
Yes, since 5.8.1. The problem is that the now old linux-threads implementation
returns different values for getpid() and getppid() for different threads.
Hence Perl decides better to cache these values and update the cache on
fork() to make it more compatible with other thread implementations. Since
Apache does its own fork the cache is not updated. Mp2 contains code that
handles the situation but mp1 does not.
For more information see also
http://www.gossamer-threads.com/lists/perl/porters/193162
http://www.gossamer-threads.com/lists/perl/porters/175806
Dave, have you tried the proposed approach from the thread you mentioned?
> PerlModule Perl::AfterFork
> PerlModule Apache::Constants
> PerlInitHandler "sub {Perl::AfterFork::reinit(); return Apache::OK;}"
>
> or
>
> PerlModule Perl::AfterFork
> PerlInitHandler "sub {Perl::AfterFork::reinit();}"
If you are working on Apache::SizeLimit maybe you could incorporate also
Linux::Smaps for newer kernels. Also the problem of counting out of core
pages could be addressed at least in the docs, see
http://www.gossamer-threads.com/lists/modperl/dev/84375
Torsten
Re: Releasing an independent Apache::SizeLimit to CPAN?
Posted by Perrin Harkins <pe...@elem.com>.
Dave Rolsky wrote:
> Apache::SizeLimit has a long-standing bug on Linux where it never
> actually kills a child, because of Perl's caching of ppid info
> internally, and the way this interacts with Apache's forking.
>
> See this thread for details:
> http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EEFE1ECF72D811B384000E7F228BB7024CC6BC@DEBAGE71.BERTELSMANN.DE%3E
You're saying that it always thinks it is in the main process even
though it's actually in a child? I haven't seen this behavior. Is it
specific to certain versions of Perl or Linux?
- Perrin