apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject HTTP EnableSendfile directive and new mechanics
Date Sun, 13 Oct 2002 22:37:26 GMT
To both lists, since this patch affects APR and sendfile.

The attached patch introduces the EnableSendfile directive for httpd.  Jeff and
I have seen several cases, including NFS shares and so forth, that are not
compatible with apr_sendfile.  It works similarly to EnableMMAP but the
differences are worth discussing.  {This is why I'm posting and not yet ready
to commit.}

The EnableMMAP worked by adding a flag to the bucket.  However, it seems
very silly to do so when what we really want to toggle is the file.

We also have an issue on Win32, we weren't using the correct open file semantics.
This may have had something to do with BSoD (kernel panic) using some socket
drivers on Win32.  Opening for TransmitFile should be done with sequential
optimizations and I believe it must be opened overlapped (that XTHREAD flag.)

But the XTHREAD flag means more than just sendfile - it means multiple threads
will need atomic seek-read/write operations on all platforms.  That wasn't the
right flag to play with across the board.

So this patch proposes an APR_OPEN_FOR_SENDFILE bit, where that bit
has little impact on any platform but Win32.

BUT - it does act as a sentinal that we can sendfile the flag.  This allows us, at
the apr_file_t granularity, to choose to sendfile or not.  It also can get rid of some
nasty side effects like Win9x which can't sendfile.  We decide this at runtime, so
we will simply unset that flag if requested.

Finally, we already have the semantics to recover the flags value from an apr_file_t,
giving the HTTP core output filter the final word to sendfile or not to sendfile.

Comments welcome, I'll commit midweek if nobody hollers.


View raw message