httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: core dump in ap_send_fd
Date Fri, 21 Dec 2001 14:34:18 GMT
From: "Stas Bekman" <stas@stason.org>
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


Mime
View raw message