perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Förtsch <>
Subject modperl - quo vadis?
Date Fri, 28 Jan 2011 20:18:05 GMT
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 ...> 
    <PerlNameInterpreter myappv5> 
      PerlSwitches ... 
      PerlModule ... 
      <Perl ...> 
    <VirtualHost ...> 
      PerlUseInterpreter myapp4 
    <Location ...>
      # perhaps we can offer different interpreters even here
      # at least starting at HeaderParser
  * implement interpreter usage monitoring via mod_status

- smaller but not without pitfalls: implement a proper shutdown for

- 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 ) {

- 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 


Torsten Förtsch

Need professional modperl support? Hire me! (

Like fantasy?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message