httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: Portability of APR.
Date Tue, 14 Sep 1999 11:12:26 GMT

> >I need to think about this a bit more.  But I think it can be done in the
> >current API just fine.
> 
> Please spell out how the initialized file_t is supposed to indicate that the
> size attribute is 'unknowable'.  Any code that uses the size field
> (i.e. content-length: header generation) must also do the proper checks.

As I said, I THINK it can be done.  As a first stab in the dark, I would
suggest keeping track of how much data is read as you are reading it.
There is nothing stating that Apache must get the content-length from a
stat call on static content.  Just add up the number of bytes you have
read so far and keep track of it in the request_rec.  If we want to stat
when we can, and add up bytes when we can't, store -1 in the size field
for the apr file, and when we get -1 back from ap_get_filesize, the code
can know it has to keep track of data length itself.

> Do you mean use the last modified time as the last access time?

Yep.

> A common way to create a temporary file on Unix is to create the file
> and then unlink it so when the file is closed the file system deletes it
> because the inode has no references.  In VMS, to create a temporary
> file you tell the file system to create a file with the 'scratch' attribute
> (which has no directory entry) or create a file with the 'delete-on-close'
> attribute (directory entry exists until the file is closed).  The defined 
> semantics for ap_remove_file() tempt one to use it as a substitute for 
> unlink() that can be used in non-portable ways.

Well, the obvious way to fix this, is to have ap_remove_file not actually
remove the file from the file system.  You could create all files with
delete-on-close (bad idea), and have remove_file be a no-op.  You could
have remove_file simply mark a file as being deletable, and the garbage
collect those files after a while.  ap_remove_file was written the way it
was, because it was meant to be used a substitute for unlink.  

Or, there is always the correct way to do it.  Suggest an API for
ap_create_temp_file.  And then implement it on at least one platform, and
submit it for use in apr.  This removes the need to ap_remove_file to be
used like unlink, but still allows us to delete files.

> >#include "apr_portable.h"
> >#ifdef Win32
> >#define SEND(x, y, z) WSASend(x, y)
> >#else
> >#define SEND(x, y, z) write(x, y, z)
> >#endif
> >
> >ap_status_t write_to_network(ap_sock_t *sock, char *buf)
> >{
> >ap_os_sock_t *temp = NULL;
> >
> >ap_get_os_sock(sock, &temp); 
> >SEND(temp, buf, strlen(buf);
> >}
> 
> That assumes that if the ap_sock_t type is an int, then that int must
> be a file descriptor suitable for passing to the write() function.  This is
> a non-portable assumption that will not be caught by the compiler if violated.

The above code assumes no such thing.  In fact, the windows code above
wouldn't be using an integer.  It would be using either a Socket or a
HANDLE (I can't remember if the use HANDLE's for sockets).  Both of which
are opaque types on Windows.  The code assumes that the programmer knows
what platforms will be trying to execute this code.  Yes, it does assume
that what you get back from ap_get_os_sock is a valid socket type, but
that was garaunteed a long time ago when you created the socket.

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