httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Jones <>
Subject Re: Portability of APR.
Date Tue, 14 Sep 1999 15:14:34 GMT
In message <>,
  Ryan Bloom <> writes:
>> 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.

If you want to send back a content-length header in an HTTP response, you are
going to try to find out the size before you read any of the data.  I have
no problem using a -1 size to indicate 'unknown', you just have to explcitly
state that in the file_t description so everyone knows that's what it means.

>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.

If you unlink a file you can immediately create a new file by the same name, 
flagging an open file for delete later (e.g. when closed) will cause
problems if you try to to create a new file by the same name.

The win32 version of ap_remove_file() in the current tarball is simply 
calling the the Win32 function DeleteFile(), which fails under NT if the file 
is currently open.

>  ap_remove_file was written the way it
>was, because it was meant to be used a substitute for unlink.

That was point the I started this thread with: writing a portable API is hard
because the designer tends to innocently include functionality from his
familiar platform that are hard to implement in the general case.

>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.

Or you could just add a APR_DELETE_ON_CLOSE bit to the flag argument of 
ap_open.  On platforms that support that option on the open (such as windows),
you set attribute.  On unix, you set a flag that file_cleanup checks.

>> 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.

That code is prepared for 2 cases: Win32 and everything else.  If someone
attempts to implement APR on another platform (e.g. VMS) and decides the
best implementation for ap_sock_t is an int that is not an FD (e.g. a VMS
channel number), then that code is broken.  Code that uses platform-specific
stuff shouldn't be expected work when a new platform comes along, but
we should make it so we find out it is broken at build time rather than
run time.

My argument for platform-specific function names is that future maintainers
don't have to parse which ifdef block they are in to know which
platform this platform-specific piece of code is for.

David L. Jones               |      Phone:    (614) 292-6929
Ohio State University        |      Internet:
140 W. 19th St. Rm. 231a     |     
Columbus, OH 43210           |     

Disclaimer: Dogs can't tell it's not bacon.

View raw message