httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: MMAP support for APR
Date Fri, 15 Oct 1999 01:49:26 GMT
"David Reid" <abb37@dial.pipex.com> wrote:
>
>How do we control the lifetime of an mmap?  We need some way of stopping us
>from deleting an mmap while it is still being read.
>Similarly are there any platforms that need to restrict access to a certain
>number of simultaneous accesses?
>Is it worth making the mmap's created into a linked chain within each
>application?  This would be useful for "walking the chain" to find a
>matching mmap or to generate info on the size of mmaps presently in the
>system (thinking ahead to possibly linking with mod_status).
>At present I've used the whole stat struct as it's impossible to determine
>which fields will be used in the future.  Is this worthwhile or do we simply
>make a decision and cherry pick the fields that will be useful?

I'm going to mention Flash again because it's cool.
http://www.cs.rice.edu/~vivek/flash99/flash.ps.gz

This server does some really cool things with mmap: It maintains a
cache of chunks of mmapped files that is tuned to the available memory
in the machine and has an LRU replacement strategy to approximate the
kernel's page replacement strategy. It uses auxiliary processes to
peek at the pages of the mmap (and therefore block while they are read
in) so that the main server doesn't block. If Dean's idea of a
select-loop-based MPM happens then this could be very handy (even if
the select loop is hidden inside some userland threading library).

There are some other optimisations: Instead of cacheing struct stats,
it caches the translation of URI to filename. It's based on thttpd so
it doesn't have to worry about .htaccess files, but I like the idea of
being able to avoid traipsing around the filesystem on every request.
It also caches response headers so that they can be re-used, and does
some tricks to avoid realignment costs inside the network stack.

>ap_status_t ap_read_mmap(char * buffer, ap_size_t buflen,
>                         ap_size_t startpos, ap_size_t len,
>                         ap_mmap_t, ap_context_t)
>
>Read a section from an mmap'd file.  Start at startpos and read len
>bytes. With startpos set to 0 and len set to -1 try to read entire
>file, checking the size of the buffer.

What's the point of this? Why can't I just slurp bytes straight out of
memory?

Tony.
-- 
fanf@demon.net -- the .@ person

Mime
View raw message