From: "Stas Bekman" <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 2:09 AM
> Please suggest a portable alternative. In 1.3.x we have:
>
> include/http_protocol.h:
> API_EXPORT(long) ap_send_fd_length(FILE *f, request_rec *r, long
> length);
>
> (which supported length=-1, for 'figure it out yourself')
>
> and it's being used in many places. When people move to 2.0 what can
> they do? Their code will break since this functionality is not available
> in APR.
YES IT IS [if you use apr_file_t.]
First, you should be able to choose -1 for a file as well (can we say, SendItAll?)
If the sendfile semantic on a platform can't support SendItAll mode, then that
platform will have to resolve the size with an fstat{size}-ftell(), at that time.
Most sendfiles have no problem offering a SendItAll method.
So as far as a file bucket, we aught to support -1 all the time. {certainly
sub-optimal on some platforms, so avoid whenever you can.}
> > I doubt we will take the hit on an fstat() just to see if the coder
> > had a clue about what they were doing.
>
> Not really, in this case it's impossible to do the validation on the
> user side if you are being handed a fd and a length. How can you check?
> You don't have a path, just an already opened fd.
You need a handle for the win32 apr_os_file_put call;
((HANDLE)_get_osfhandle(fileno(fd))).
But I was also apparently wrong about opening a file especially for sendfile.
>From the PSDK;
Handle to the open file that the TransmitFile function transmits.
Since operating system reads the file data sequentially, you can improve
caching performance by opening the handle with FILE_FLAG_SEQUENTIAL_SCAN.
So that's an option, not a requirement... the other side of the coin was the
OVERLAPPED structure, but that's on the SOCKET - not on the file handle...
If the socket handle has been opened as overlapped, specify this parameter
in order to achieve an overlapped (asynchronous) I/O operation. By default,
socket handles are opened as overlapped.
Finally, the only other time that you must open the _FILE_ for overlapped IO
is when you will pass the same filehandle to the server at the same moment on
different threads [think file cache.] That's the odd APR_XTHREAD flag that
some folks have wondered about. It's there to create a 'stateless' filehandle,
if you look at the seek/read/write code in Win32, you will see we have to jump
through hoops to do simple reads, since it won't maintain a seek/tell position.
I don't expect we will support that at all through apr_os_file_put.
Bill
