httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: cvs commit: apache-2.0/mpm/src/main iol_unix.c Makefile.tmpl buff.c http_connection.c http_protocol.c http_request.c
Date Sun, 20 Jun 1999 03:50:02 GMT
On Sat, 19 Jun 1999, Dean Gaudet wrote:

> No, I'm on crack.  We don't need that complexity... here's what I'm going
> to play with: 
> typedef struct ap_bufel ap_bufel;
> struct ap_bufel {
>     ap_bufel *next;
>     char *start;                        /* first byte */
>     char *end;                          /* last byte + 1 */
>     void (*free)(ap_bufel *e);          /* never NULL */
>     void *data;                         /* for use by free() */
> };
> typedef struct ap_buf ap_buf;
> struct ap_buf {
>     ap_bufel *head;
>     ap_bufel **tail;
> };
> For example, for shared mmap caches, the mutex/ref_count stuff can be done
> by the free() function. 

Feh.  This doesn't do it either. 

This wastes too much memory... because you allocate, say, a 4k buffer and
write into it, then switch to chunking, you create a bufel of the stuff
you have written so far, and append it to a buf.  Then you chunk for a
bit, into another 4k buffer, finish up, create a bufel, and append that to
the buf.  Pretty soon you've got all these little bits and pieces, each
occupying 4k, lots of fragmentation. 

The ref_count stuff I posted earlier is one way to solve it -- you can
continue to use the same 4k buffer... and pretty soon it gets really
complex and is questionably faster. 

I'm giving up.  The only thing that I need this fancy stuff for is
chunking -- everything else (encryption, compression, and the OS
abstraction) can do with a simple read/write style interface.  I'm going
to re-implement chunking the same way it is in 1.x... as part of BUFF. 
It's got a few twists to deal with non-blocking i/o though, sigh.

I had hoped to remove chunking only because it might simplify buff.c ... 
but it's really a thorny problem, so let it be thorny code. 


View raw message