httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <ab...@dial.pipex.com>
Subject MMAP support for APR
Date Thu, 14 Oct 1999 18:19:02 GMT
Hi,

Below is a very early overview of what I'm proposing we do to add mmap to
APR.  This is the very basics and I'm open to suggestions.

I'm posting now as I'm off to deliver an aircraft in 3 days time and will be
totally out of contact (as much by choice as anything alese) for 6 days.  My
aim is that unless anyone else writes the code before I get around to it
then by the time I return most of the issues will have been fleshed out on
the list and I can get on with writing the first hash of the code.  As I say
if anyone has a few spare moments and wants to get on with then please feel
free.

Once the basics are in place I envisage a set of helper functions being
added to do things like find an ap_mmap_t using a filename, compare 2
ap_mmap_t's and so on.

david


MMAP for APR

The aim is to build as open an API as possible to allow us to do all the
things that 1.3
does with MMAP files but for every platform.

Basic Structure

 pointer to base address of mmap'd area
 size of mmap'd area
 stat details
 filename

Unix
  struct mmap_t {
   char *filename;
   struct stat st;
   void *mm;
   size_t size;
  };

BeOS
  struct mmap_t {
   char *filename;
   struct stat st;
   area_id areaid;
   void *mm;
   size_t size;
  }


Questions?

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?

API prototypes

ap_status_t ap_create_mmap(ap_mmap_t, char *filename, ap_context_t)

Create a new mmap area and read the file into it.

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.

ap_send_mmap(ap_socket_t, apint32 startpos, apint32 len, ap_mmap_t,
ap_context_t)

Send a section of an mmap'd file to a socket.  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.

ap_delete_mmap(ap_mmap_t)

Delete the mmap area.




Mime
View raw message