httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: sendfile() / Moving iol_socket to APR / abstractions in http_core
Date Thu, 11 Nov 1999 19:38:51 GMT

Okay, lots of stuff here, one thing at a time.

> So I think this leaves us with a few possibilities to consider:
> - Eliminate the #ifdefs in the main code by abstracting in APR.  This
> would mean using ap_sendfile in ap_send_fd and providing a new
> implementation of ap_sendfile for OSes that don't have the actual system
> call.  That would be a simple, standard read/write loop.  This seems like
> a necessity to allow APR to truly provide the same API on all platforms.
> - It seems to me that sendfile() and mmapped files are mutually exclusive
> strategies to quickly transmit an entire file.  If we moved the mmap code
> from default_handler to the new ap_sendfile, it would eliminate a lot of
> #ifdef'd cruft from the main module.  This would put all the
> platform-specific performance tweaks into APR where they, IMHO, probably
> should be.  We can always provide a NO_MMAP flag for ap_sendfile that
> ensures no memory mapping will be used, if in some case it would be
> undesirable.

If I understand you properly, you want APR to implement ap_sendfile, and 
you want ap_sendfile to either use sendfile or mmap under the covers,
depending on what the platform provides.

I agree with the first half, and it's coming.  We are going to put
sendfile into APR.  Somebody just has to do it.  I haven't had the time
recently, and I haven't seen any patches yet.  hint hint.

I disagree completely with the second part.  APR will provide feature
macros, APR_HAS_SENDFILE and APR_HAS_MMAP.  Let Apache decide which of
these should be used and when.  ap_sendfile should implement sendfile and
only sendfile.  If sendfile doesn't exist, then we won't define that
feature macro.  apr_mmap_* should use mmap and only mmap, again if mmap
doesn't exist on a given platfrom, APR_HAS_MMAP won't be defined.

> - Both Linux and FreeBSD allow you to specify an offset into the file in
> the sendfile() API.  I don't believe that Win32 TransmitFile() allows
> this.  It would allow ap_send_fd_length to be implemented with sendfile
> as well.  How often in practice is ap_send_fd_length really used to
> transmit files of a decent size?  I have no idea whether this change
> would make a noticeable performance difference, so it probably isn't
> worth doing unless Win32 does have some hidden offset specification.

I suggest ignoring this for now, and maybe coming back to it in the near
future.

> I think that these little changes could clean up http_core and the
> default handler significantly, while also making APR more useful and
> improving performance.  I'd be glad to do the patches myself, if you all
> think it's a reasonable strategy.

Any patches that are submited will be considered.  I say give us the code,
and let's take a look.  :)

> Finally, I'd like to put in a vote for the "option 1" method of
> incorporating iol_socket into APR (the non-linked-list version).  It
> seems much simpler and I don't really see a performance difference.

Afraid I don't understand what you mean.  The only discussion of linked
lists was in the second half of the note, and both options involved linked
lists.  The second half of the note was only intended to show where IOL's
will be going at some point.  AFAIK, we have decided not to put layering
into 2.0, because we want to put a stable release out soon, and layering
just adds to much new feature to 2.0.

The top half of the note had more to do with the 2.0 design, namely should
APR types be filling in the function pointers, or should IOL's have their
own types with their own functions?

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	



Mime
View raw message