You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Torsten Förtsch <to...@gmx.net> on 2011/01/28 21:18:05 UTC
modperl - quo vadis?
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
RE: modperl - quo vadis?
Posted by Steve Hay <St...@planit.com>.
Torsten Förtsch wrote on 2011-02-02:
> On Monday, January 31, 2011 09:29:51 Steve Hay wrote:
>> Yes, I build on Windows and care about Windows support. It all works
>> pretty-much out-of-the-box for me, certainly on XP using VS2008 (VC9)
>> (either the full commercial version, or the free Express version):
>>
>> Build Perl: nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef
>> PERL_MALLOC=define nmake INST_TOP=C:\perl5 CCTYPE=MSVC90
>> USE_IMP_SYS=undef PERL_MALLOC=define test
>
> ok, I tried vs2010 + perl 5.13.9 on vista.
>
> Compilation went without problems. While making test a few tests are
> skipped, most are ok. But porting/buildtoc.t fails and now the test
> suite is stalled in cpan/Archive-Extract/t/01_Archive-Extract.t ... 342/?
>
> So, again I am failing on the preliminaries, :-(
>
> With perl 5.12.3 it stalled a bit earlier.
I normally build on XP at the moment, which is working fine for me. Maybe you get the odd test failure on other OSes, I'm not sure. I think I've seen Archive-Extract trouble before when I've had gzip/zip/tar programs in the PATH (e.g. having Cygwin's bin folder in the PATH might interfere). If you're on Vista or higher it might also be worth turning off UAC (User Account Control), which I generally find is more trouble than it's worth.
If you get a test hanging then Process Explorer [1] is really good for showing a tree view of running processes: simply kill the perl.exe at the bottom of the tree of processes comprising the test suite and that will kill that one test and allow the remainder to continue.
You can always run individual failed tests later, of course, to examine why they failed.
[1] http://technet.microsoft.com/en-us/sysinternals/bb896653
---------------------------------------------------------------------
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 Monday, January 31, 2011 09:29:51 Steve Hay wrote:
> Yes, I build on Windows and care about Windows support. It all works
> pretty-much out-of-the-box for me, certainly on XP using VS2008 (VC9)
> (either the full commercial version, or the free Express version):
>
> Build Perl:
> nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define
> nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define
> test
ok, I tried vs2010 + perl 5.13.9 on vista.
Compilation went without problems. While making test a few tests are skipped,
most are ok. But porting/buildtoc.t fails and now the test suite is stalled in
cpan/Archive-Extract/t/01_Archive-Extract.t ... 342/?
So, again I am failing on the preliminaries, :-(
With perl 5.12.3 it stalled a bit earlier.
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 Torsten Förtsch <to...@gmx.net>.
On Monday, January 31, 2011 09:29:51 Steve Hay wrote:
> Yes, I build on Windows and care about Windows support.
good to know that modperl gets a bit of testing on windows too.
> Perl support for VS2010 (VC10) is now in bleadperl (including 5.13.9), but
> not quite complete yet. VS2005 (VC8), VS2003 (VC7) and VC6 used to work
> too and probably still do (but some of the earlier free Express versions
> have various dependencies on SDKs etc: the VS2008 or VS2010 versions are
> better because they are self-contained).
Thank you very much!
I'll try that out next weekend.
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 Torsten Förtsch <to...@gmx.net>.
On Monday, January 31, 2011 09:29:51 Steve Hay wrote:
> Yes, I build on Windows and care about Windows support. It all works
> pretty-much out-of-the-box for me, certainly on XP using VS2008 (VC9)
> (either the full commercial version, or the free Express version):
>
> Build Perl:
> nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define
> nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define
> test nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef
> PERL_MALLOC=define install
So, finally that step is done. Here is what I have done:
- installed a German XP Home in a KVM virtual machine
- installed VS2008
Then the tricky part begins. On a German XP the home directory looks like
"C:\Dokumente und Einstellungen\...". My first naive try was to create a
subdirectory there and nmake && nmake test. But then nmake test gives you a
lot of errors of the type "program C:\Dokumente not found".
So, there are 2 points that I have found:
- don't use vista, haven't tried win7
- don't use directory names with blanks
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 Steve Hay <St...@planit.com>.
Torsten Förtsch wrote on 2011-01-28:
> 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.
>
Yes, I build on Windows and care about Windows support. It all works pretty-much out-of-the-box for me, certainly on XP using VS2008 (VC9) (either the full commercial version, or the free Express version):
Build Perl:
nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define
nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define test
nmake INST_TOP=C:\perl5 CCTYPE=MSVC90 USE_IMP_SYS=undef PERL_MALLOC=define install
Build Apache:
nmake /f Makefile.win INSTDIR=C:\apache2.2 installr
Install apxs:
perl Configure.pl --with-apache2=C:/apache2.2 --with-apache-prog=httpd.exe
Build mod_perl2:
perl Makefile.PL MP_AP_PREFIX=C:/apache2.2
nmake
nmake test
nmake install
Build libapreq2:
[Make sure C:\apache2.2\conf\httpd.conf loads mod_perl]
perl Makefile.PL
nmake
nmake test
nmake install
There are a few test failures that I get but haven't had a chance to look into yet (apache/subprocess tests 2-5, hooks/authen_basic test 4, hooks/authz test 4 and modules/apache_status tests 14-15).
I don't personally use OpenSSL in my mod_perl setup, but do use it for other purposes. It also builds fine on Windows:
perl Configure VC-WIN32 --prefix=/openssl --openssldir=/openssl
ms\do_ms
nmake /f ms\nt.mak
cd out32
..\ms\test
cd ..
nmake /f ms\nt.mak install
Perl support for VS2010 (VC10) is now in bleadperl (including 5.13.9), but not *quite* complete yet. VS2005 (VC8), VS2003 (VC7) and VC6 used to work too and probably still do (but some of the earlier free Express versions have various dependencies on SDKs etc: the VS2008 or VS2010 versions are better because they are self-contained).
---------------------------------------------------------------------
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.
Re: modperl - quo vadis?
Posted by 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 Fred Moyer <fr...@redhotpenguin.com>.
On Fri, Jan 28, 2011 at 1:19 PM, Adam Prime <ad...@utoronto.ca> wrote:
>
>> - how long do we want to support old perl versions?
>
> I think we should use the same policy that the perl core uses, which is
> here:
>
> http://search.cpan.org/dist/perl/pod/perlpolicy.pod
>
> This would mean the currently, we are only explicitly supporting 5.10 and
> 5.12, assuming i'm reading it right.
This is a must read for this issue - http://rjbs.manxome.org/rubric/entry/1872
I'm a bit uneasy about not supporting 5.8.8, but maybe I'm just behind
the times. However, most of the enterprise users (big companies) that
I know of are on 5.8. One shop was on 5.6; am not sure if they have
upgraded yet.
The issue that often comes up is 'what business value do we gain from
upgrading?' The obvious answer is you get an actively supported
version. In practical matters, that turns out to matter very little.
How often do you hear about people upgrading because of a security or
bugfix issue? Rarely in my experience (not that it doesn't happen,
but just not often).
So what other business value is there in upgrading Perl versions?
There is negative value if you have to upgrade XS code, and negative
value if you have fix parts of your code. I did a test upgrade of one
large application to 5.8.8 from 5.6.2, and it took a couple dozen
hours of work. The benefits turned out to be a small speed increase
(~10% on benchmarks), and the use of 5.8 unicode goodness. Those were
tangible benefits that management understood, but they were small.
The intangible benefits were only understood by the developers; a
debugger that actually worked, smart match (with 5.10), and general
increased developer efficiency. However, since your boss and his boss
can't relate to these benefits, they effectively don't exist.
Putting all my emotion aside, I think we should support whatever Perl
and Apache versions the respective organizations designate as not
being end of life :)
>
>> - can we really support windows?
>
> I don't know if there is expertise within the PMC with regards to windows
> anymore since Randy's passing. That said, there are windows resources out
> there that could possibly be tapped, the strawberry perl people, #win32.
>
> For the TODO stuff, a lot of those things sound like good ideas, and i would
> do what i can to support them happening, but i don't really have the C foo
> to work on it. I can however write tests, and am up for doing that.
>
> Adam
>
> ---------------------------------------------------------------------
> 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 Adam Prime <ad...@utoronto.ca>.
> - how long do we want to support old perl versions?
I think we should use the same policy that the perl core uses, which is
here:
http://search.cpan.org/dist/perl/pod/perlpolicy.pod
This would mean the currently, we are only explicitly supporting 5.10
and 5.12, assuming i'm reading it right.
> - can we really support windows?
I don't know if there is expertise within the PMC with regards to
windows anymore since Randy's passing. That said, there are windows
resources out there that could possibly be tapped, the strawberry perl
people, #win32.
For the TODO stuff, a lot of those things sound like good ideas, and i
would do what i can to support them happening, but i don't really have
the C foo to work on it. I can however write tests, and am up for doing
that.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org