httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Buffered file I/O & thread safety
Date Tue, 13 Jun 2000 17:21:23 GMT

> > Err, considering that the calls actuall affected are ap_read & ap_write
> > that would require finding & changing all occurances of those calls. I much
> > prefer a single flag change to ap_open. It aint 'Tons' of flag checking,
> > just one.
> There's lots of flag checking for APR_READ/WRITE/etc., APR_OS_DEFAULT,
> DELONCLOSE, APR_BUFFERED, etc. This is an added flag.

This doesn't address any of what is in the previous message.  If we make
the locking/no-locking thing a separate function that basically calls
ap_read/ap_write, we have to find and consider all of the calls
ap_read/ap_write to determine if they should use ap_read/ap_write or
ap_fread/ap_fwrite.  With adding one flag to ap_open, we just have to find
and fix the calls to ap_open.  

Yes, ap_open does a lot of flag checking.  This is required for
portability.  It is a PITA, but it is required.  If you can find a way to
remain portable and avoid all of the flag checking, I would love to hear

> The important part isn't readability of the patch, but readability of
> the entire function.
> ap_open is 75 lines long (generously spaced, but still...). This is
> all overhead that is required, both for a person trying to parse the
> code and for the actual running of the code, and none of this actually
> includes the OS's work of opening a file. ap_open isn't as hard to
> read as ap_read, yet.

The entire ap_open function is relatively clean.  We check a bunch of
flags, and open the file.  I haven't seen a suggestion for how to clean up
the ap_open function yet.  Every flag that has been added to ap_open has
been added to support a specific platform.  I do not believe we are
talking about a great deal of overhead.  I can see some places that we can
cleanup some of the overhead of the checks, but not much.

Remember that most of APR has never been optimized.  The goal was to get
APR working, and optimize it later.  I expect APR to be radically changed
(the source not the API's) for performance sometime between 2.0.0 and
2.0.1.  This is not an optimization that needs to be done before 2.0.0 is
actually release IMHO.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message