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-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
