You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Fred Moyer <fr...@redhotpenguin.com> on 2011/02/01 08:32:15 UTC
Re: modperl - quo vadis?
Another thing that comes to mind after rolling the 2.0.5 rc is that we
should start shipping the Apache-* based modules separately as CPAN
distributions when we release 2.0.6.
The MY::test section in Makefile.PL will need to be overriden so that
it skips the test suit if Apache-Test isn't present. The code to do
that is in a couple of other Makefile.PL files, and it pretty solid at
this point.
We should be moving towards more modularity; trying to get mod_perl
2.0.5 out has definitely seen the coupling of the Apache::* modules to
it as a bottleneck. I think that if we can remove the Apache::*
modules from the distribution with 2.0.6, Gozer may be able to work
his magic and decouple APR::* from mod_perl in 2.0.7. Wouldn't that
be cool :)
2011/1/28 Torsten Förtsch <to...@gmx.net>:
> Hi all,
>
> a few questions that come up in my head every time when I think about modperl:
>
> - how long do we want to support old perl versions?
>
> For example, modern perls do not support anything but the perlio model. Stdio
> was officially dropped in 5.8.7 or so. If you need to change some of the
> related code in modperl it becomes really hard to test it. Older perls do not
> compile in a modern environment and newer perls perhaps can be built without
> perlio but the test suite will fail for sure.
>
> - can we really support windows?
>
> Do we have any developer who builds/tests/cares about modperl on windows? If
> yes, I withdraw the question. If not, how can we claim modperl runs on
> windows? I have tried to build apache & modperl on windows. But my last
> encounter with it as a developer dates back to the mid-nineties. So I failed
> badly already on the preliminaries. That doesn't mean anything if we have
> someone on the team who can.
>
> BTW, could this someone please document in a fool-proof way (for me) how to
> build modperl on windows starting with which compilers to use? Where do I get
> or how do I build an usable openssl, that sort of stuff. Suppose you have a
> freshly installed Vista or Win7 virtual machine.
>
>
>
> Perhaps, a few more points to discuss. They are a bit of a TODO list what
> could be improved in modperl:
>
> - big: refactor threading code
> * implement a fixed sized interpreter pool
> * start perl interpreters before forking off worker children (use COW at
> least a bit)
> * implement PerlInterpInit and PerlInterpExit phases (like ChildInit/Exit)
> these hooks are run by the worker processes for each interpreter. Do we
> need also per thread init/exit phases? I doubt that, but ...
> * make -Dusemultiplicity -Uuseithreads possible
> * improve "PerlInterpScope handler" (mainly by writing test cases)
> * better configuration (instead of +Parent and similar):
> <PerlNameInterpreter myappv4>
> PerlSwitches ...
> PerlModule ...
> <Perl ...>
> </Perl>
> </PerlNameInterpreter>
> <PerlNameInterpreter myappv5>
> PerlSwitches ...
> PerlModule ...
> <Perl ...>
> </Perl>
> </PerlNameInterpreter>
> <VirtualHost ...>
> PerlUseInterpreter myapp4
> ...
> </VirtualHost>
> <Location ...>
> # perhaps we can offer different interpreters even here
> # at least starting at HeaderParser
> </Location>
> * implement interpreter usage monitoring via mod_status
>
> - smaller but not without pitfalls: implement a proper shutdown for
> $r->child_terminate
>
> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
>
> - small: fix the leak in (reuse the brigade instead of allocating a new one
> from the pool)
>
> while( my $chunk=get_some_chunk ) {
> $r->print($chunk);
> $r->rflush;
> }
>
> - small: I believe we have a leak with a perl that is compiled with
> "-Dusemultiplicity -Duseithreads" and code of the type
>
> $r->push_handlers( Perl*Handler => sub {...} );
>
> or in a .htaccess file
>
> Perl*Handler "sub {...}"
>
> where the actual handler is a anonymous subroutine or a closure.
>
> - implement a way to untie %ENV after fork() in a handler
>
> - there is Parse::Perl on CPAN. With a few tweaks that could be used or some
> ideas be adopted to improve Modperl::Registry
>
> - better support for other MPMs
>
> Sometimes it itches me to tackle the big one. But then that is minimum 4-8
> weeks full time for me. With tests and documentation even longer. Last year I
> couldn't afford that. I doubt this year. It's quite a large chunk of my yearly
> income.
>
> Thoughts?
>
> Torsten Förtsch
>
> --
> Need professional modperl support? Hire me! (http://foertsch.name)
>
> Like fantasy? http://kabatinte.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl - quo vadis?
Posted by Torsten Förtsch <to...@gmx.net>.
On Friday, February 04, 2011 00:38:25 Philip M. Gollucci wrote:
> >>> - big: refactor threading code
>
> I'd loved to see your thread branch merged in.
me too, that would be a start. That branch works here in production. It works
on my linux with and without threads. The main obstacle for me to move forward
is windows. Would be good to test it there before the merge.
But here I am already failing on the preliminaries:
http://www.gossamer-threads.com/lists/perl/porters/260496#260496
Hence the question about windows.
I have got a win7 oem version with a new computer. My next try would be to
install that thing in a virtual machine and try again. But I wouldn't mind if
someone with more windows wits jumps in.
> >>> * make -Dusemultiplicity -Uuseithreads possible
>
> I'm not really sure this is a big gain, for a tremendous amount of effort.
multiplicity is about multiple interpreters, threads about synchronization.
For +Parent with prefork we don't need the latter. But I agree it's probably
not a big win.
Perhaps it could be a by-product of the general refactoring if kept in mind.
> >>> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
>
> Yes!
>
> >>> - implement a way to untie %ENV after fork() in a handler
>
> Thats a rough one b/c of the way its coded. see also local %ENV bombing.
I have feared someone would say that. I had a look at the code some time ago
and yes, I think so too.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl - quo vadis?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
On 02/01/11 07:37, Fred Moyer wrote:
> Actually, I think it would be more appropriate to do 2.0.6 with the
> Apache::* decoupling, then 2.2.0 for the APR::* decoupling.
>
This would also pave the way for APR::DBD wrappers for mod_dbd which
I've been interested in for quite some time but enotime.
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer, FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: modperl - quo vadis?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
On 02/01/11 07:37, Fred Moyer wrote:
>>> - how long do we want to support old perl versions?
100% in favor of dropping < 5.8.[89]
>>>
>>> For example, modern perls do not support anything but the perlio model. Stdio
>>> was officially dropped in 5.8.7 or so. If you need to change some of the
>>> related code in modperl it becomes really hard to test it. Older perls do not
>>> compile in a modern environment and newer perls perhaps can be built without
>>> perlio but the test suite will fail for sure.
Absolutely +1
I'd like to see httpd mins upped substantially too.
>>> Perhaps, a few more points to discuss. They are a bit of a TODO list what
>>> could be improved in modperl:
>>>
>>> - big: refactor threading code
I'd loved to see your thread branch merged in.
>>> * make -Dusemultiplicity -Uuseithreads possible
I'm not really sure this is a big gain, for a tremendous amount of effort.
>>> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
Yes!
>>> - implement a way to untie %ENV after fork() in a handler
Thats a rough one b/c of the way its coded. see also local %ENV bombing.
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer, FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: modperl - quo vadis?
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Actually, I think it would be more appropriate to do 2.0.6 with the
Apache::* decoupling, then 2.2.0 for the APR::* decoupling.
2011/1/31 Fred Moyer <fr...@redhotpenguin.com>:
> Another thing that comes to mind after rolling the 2.0.5 rc is that we
> should start shipping the Apache-* based modules separately as CPAN
> distributions when we release 2.0.6.
>
> The MY::test section in Makefile.PL will need to be overriden so that
> it skips the test suit if Apache-Test isn't present. The code to do
> that is in a couple of other Makefile.PL files, and it pretty solid at
> this point.
>
> We should be moving towards more modularity; trying to get mod_perl
> 2.0.5 out has definitely seen the coupling of the Apache::* modules to
> it as a bottleneck. I think that if we can remove the Apache::*
> modules from the distribution with 2.0.6, Gozer may be able to work
> his magic and decouple APR::* from mod_perl in 2.0.7. Wouldn't that
> be cool :)
>
> 2011/1/28 Torsten Förtsch <to...@gmx.net>:
>> Hi all,
>>
>> a few questions that come up in my head every time when I think about modperl:
>>
>> - how long do we want to support old perl versions?
>>
>> For example, modern perls do not support anything but the perlio model. Stdio
>> was officially dropped in 5.8.7 or so. If you need to change some of the
>> related code in modperl it becomes really hard to test it. Older perls do not
>> compile in a modern environment and newer perls perhaps can be built without
>> perlio but the test suite will fail for sure.
>>
>> - can we really support windows?
>>
>> Do we have any developer who builds/tests/cares about modperl on windows? If
>> yes, I withdraw the question. If not, how can we claim modperl runs on
>> windows? I have tried to build apache & modperl on windows. But my last
>> encounter with it as a developer dates back to the mid-nineties. So I failed
>> badly already on the preliminaries. That doesn't mean anything if we have
>> someone on the team who can.
>>
>> BTW, could this someone please document in a fool-proof way (for me) how to
>> build modperl on windows starting with which compilers to use? Where do I get
>> or how do I build an usable openssl, that sort of stuff. Suppose you have a
>> freshly installed Vista or Win7 virtual machine.
>>
>>
>>
>> Perhaps, a few more points to discuss. They are a bit of a TODO list what
>> could be improved in modperl:
>>
>> - big: refactor threading code
>> * implement a fixed sized interpreter pool
>> * start perl interpreters before forking off worker children (use COW at
>> least a bit)
>> * implement PerlInterpInit and PerlInterpExit phases (like ChildInit/Exit)
>> these hooks are run by the worker processes for each interpreter. Do we
>> need also per thread init/exit phases? I doubt that, but ...
>> * make -Dusemultiplicity -Uuseithreads possible
>> * improve "PerlInterpScope handler" (mainly by writing test cases)
>> * better configuration (instead of +Parent and similar):
>> <PerlNameInterpreter myappv4>
>> PerlSwitches ...
>> PerlModule ...
>> <Perl ...>
>> </Perl>
>> </PerlNameInterpreter>
>> <PerlNameInterpreter myappv5>
>> PerlSwitches ...
>> PerlModule ...
>> <Perl ...>
>> </Perl>
>> </PerlNameInterpreter>
>> <VirtualHost ...>
>> PerlUseInterpreter myapp4
>> ...
>> </VirtualHost>
>> <Location ...>
>> # perhaps we can offer different interpreters even here
>> # at least starting at HeaderParser
>> </Location>
>> * implement interpreter usage monitoring via mod_status
>>
>> - smaller but not without pitfalls: implement a proper shutdown for
>> $r->child_terminate
>>
>> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
>>
>> - small: fix the leak in (reuse the brigade instead of allocating a new one
>> from the pool)
>>
>> while( my $chunk=get_some_chunk ) {
>> $r->print($chunk);
>> $r->rflush;
>> }
>>
>> - small: I believe we have a leak with a perl that is compiled with
>> "-Dusemultiplicity -Duseithreads" and code of the type
>>
>> $r->push_handlers( Perl*Handler => sub {...} );
>>
>> or in a .htaccess file
>>
>> Perl*Handler "sub {...}"
>>
>> where the actual handler is a anonymous subroutine or a closure.
>>
>> - implement a way to untie %ENV after fork() in a handler
>>
>> - there is Parse::Perl on CPAN. With a few tweaks that could be used or some
>> ideas be adopted to improve Modperl::Registry
>>
>> - better support for other MPMs
>>
>> Sometimes it itches me to tackle the big one. But then that is minimum 4-8
>> weeks full time for me. With tests and documentation even longer. Last year I
>> couldn't afford that. I doubt this year. It's quite a large chunk of my yearly
>> income.
>>
>> Thoughts?
>>
>> Torsten Förtsch
>>
>> --
>> Need professional modperl support? Hire me! (http://foertsch.name)
>>
>> Like fantasy? http://kabatinte.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>> For additional commands, e-mail: dev-help@perl.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl - quo vadis?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
On 02/01/11 07:32, Fred Moyer wrote:
> Another thing that comes to mind after rolling the 2.0.5 rc is that we
> should start shipping the Apache-* based modules separately as CPAN
> distributions when we release 2.0.6.
Last I heard this was for historical reasons, but I'm like hey this 2.x.
We can always do version 2.2 or 3.0 if it makes people expect changes
more easily.
> We should be moving towards more modularity; trying to get mod_perl
> 2.0.5 out has definitely seen the coupling of the Apache::* modules to
> it as a bottleneck. I think that if we can remove the Apache::*
> modules from the distribution with 2.0.6, Gozer may be able to work
> his magic and decouple APR::* from mod_perl in 2.0.7. Wouldn't that
> be cool :)
And maybe even use apr 1.x interfaces instead of 0.9.x
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer, FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.