httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: Core server caching
Date Fri, 30 Oct 1998 04:16:37 GMT
Dean Gaudet writes:
>On Thu, 29 Oct 1998, Rasmus Lerdorf wrote:
>> There are also weird and wacky things you would be able to do if you could
>> stack mod_php on top of mod_perl.
>You people scare me.
>Isn't that redundant though?

Yes it's scary, but oddly erotic, when these behemoths with their
gigantic interpreters try to mate.

It's interesting syndrome, systems as soon as they get an interpreter
they tend to loose their bearings and grow into vast behemoths that
lumber about slowly crushing little problems with their vast mass.
Turing syndrome?

I've heard people say modules can help avoid this, but I've rarely
seen it.  Olde Unix kinda manages it remember being frightened by

Can we nudge alloc.c/buff.c toward a bit of connective glue that
continues to let individual modules evolve their own gigantism while
avoiding vile effects on the core performance of the server?  Stuff
like this:

  memory chunk alignment for optimal I/O
  memory hand off along the pipeline
  memory hand off crossing pool boundaries
  memory hand off in zero copy cases
  transmit file
  transmit cache elements
  insert/remove cache elements
  leverage unique hardware and instructions

That memcpy in ap_bread really bugs me.

I'd be rather have routines that let me handoff chunks.  Presumably
these would need to be able to move chunks across pool and buffer
boundaries.  But zero copy if I don't touch the content and never a
memcpy just to let my lex the input.

I've built systems like this with the buffers exposing a emacs
buffer style of abstraction, but with special kinds of marks
to denote what's released for sending, and what's been accepted
and lex'd on the input side.  It does create mean all your
lexical and printf stuff has to be able to smoothly slide
over chunk boundaries.

 - ben

View raw message