Hi dev,

As I am very interrested in getting perchild or something similair
working.

I've looked at perchild many times, I've never seen it work, thus I looked
at what Enrico Weigelt (from metux.de) is working on.

He has said on this list before, that it's in a somewhat useable state,
he's right. I've looked at his patch (got on the mailinglist and asked for
it), I'm impressed (although I'm easily impressed :-) ). I've tested it
against 2.0.43, not 2.1-dev from CVS yet, but will do soon.

Some parts and pieces are still missing, but it's stable the way it is (as
far as I've been able to figure out), it's a good base to build from.

It does 'graceful' restarts (although I haven't checked how graceful it
really it), unlike perchild.

After looking at it, I've been hacking on it myself to get it in an even
more useable state, (temporarily) fixed problems with keep-alives (by not
allowing them) and added all the proper headers. I'm looking into getting
'POST'-bodies working next or getting the IP-adres of the client in the
logs.

All around it seems to work better then perchild (which is still broken),
what I'd like to do is make it complete. But there are some things I'd
like to know:

1. Since before november in the httpd-2.0 Status message's [0] that get
send to this list, it includes this message:

'    * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
      how the Perchild MPM should be re-written.  It hasn't worked
      correctly since filters were added because it wasn't possible to
      get the content that had already been written and the socket at
      the same time.  This mode lets us do that, so the MPM can be
      fixed.'

But it never get's fixed, also it sounds like it will never get rid of
some of the security concerns some people have had with connecting a
debugger on a personally owned process and see all the interprocess
requests fly by. So I guess perchild just isn't such a great option, am I
right ?

2. In those same status messages, it said:

'    * Get perchild to work on platforms other than Linux. This
      will require a portable mechanism to pass data and file/socket
      descriptors between vhost child groups. An API was proposed
      on dev@apr:
        Message-ID: <[EMAIL PROTECTED]>'

That would be nice, but no1 seems to be working on that either, or is
there ?

3. What do people think of the idea of a multiplexer [1] ?

4. An obvious question of a 'user' (who can do some programming) like me
is, what will happen if it does get to a useable state, will it go into
CVS (in server/mpm/experimental/ for example) eventually and give it more 
exposure. In theory it would make it easier to maintain it (for me
atleast).

5. If so what name should it get, because the author now put his (company
?) name on it, I'm not so sure that would be a good idea, although it's a
great way to give credit. Maybe the original name was
beter: multiplexerMPM ?

As Enrico Weigelt hasn't put up any patches on the web, I've put his
latest patch (you'll need to run buildconf because it's a new MPM) and my
latest patch (on top of his patch) up on the web [2]. I will update it,
everytime he posts it on his mailinglist.

I really hope Apache gets a really good uid-/gid-assigned MPM-system,
because it would make life so much easier.

tia,
        Leen.

[0] http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=104027315618133&w=2
[1] http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=103838103217676&w=2
[2] http://www.wirehub.nl/~leen/apache/

____________________________________________________________________
Nobody said open source is easy, you want it ? Then you do the work.

Reply via email to