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 15:29:46 GMT

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

Actually, it doesn't REALLY need to be explicitly stated.  If the code is
written properly to check return codes.  Consider (pseudocode):

ap_status_t stat;
ap_size_t len;
stat = ap_get_file_length(thefile, &len);
if (stat != APR_SUCCESS) {
    while !done reading {
        read and count # of bytes;
    }
}

set_header(Content-Length, len);

send_headers;
send body;

If you return the correct status code from your functions, there is no
problem, assuming you also change the Apache code to work properly.  If
you will look at the status code I have implemented, I left plenty of room
for other ports to define return mire codes where appropriate.

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

Which is why I didn't suggest implementing it that way.  I gave three work
arounds.  The one I liked was in the next paragraph.

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

That's just not true.  As long as the file is opened shared for delete,
which ALL APR files are, this works just fine.

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

Yes, that's another option.  But, it doesn't negate the need for a way to
delete a file that isn't open. Which is what ap_remove_file does.  If you
would like this, then GET INVOLVED.  Submit a patch.  This project is
being and has been written in OPEN SOURCE.  The whole time it was being
designed and implemented, everything has been available to the public.  If
you have a problem with an API, write a patch.  Do not tell me how to fix
it, because I have FAR TOO MUCH on my own plate right now.  Fix it
yourself.

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

You obviously missed the first line of my paragraph.  The code was
written, to ASSUME that the programmer knows what platforms their code
will be executed on.  I wrote for two cases, because I was trying to prove
a point, not implement a working function.  Would I write code for VMS?
No, I haven't used VMS for about three years, and then I only used it to
read e-mail when I was at Digital.  I don't know enough about VMS to write
code for that platform.

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

The problem with this approach, is that you end up with:

ap_os_file_t *foobar;

#if WIN32
    ap_get_win32_file(thefile, &foobar);
#elif VMS
    ap_get_vms_file(thefile, &foobar);
#elif OS2
    ap_get_os2_file(thefile, &foobar);
...
#endif

OR you will get:

void foo(ap_file_t bar);
#if WIN32
    HANDLE foobar;
    ap_get_win32_file(bar, &foobar);
...
#elif VMS
    FOOBAR foobar;  (because it could be anytype)
    ap_get_vms_file(bar, &foobar);
...
#elif 
.....

What makes this any better than what is currently being done?  The only
difference I see, is that if the programmer is CAREFUL with the current
code, they can still keep the abstraction a bit longer, and the ifdefs can
be avoided all together, by simply putting those functions that require
native types in their own files.  Like we do now with the os/foo/
directories.

These functions are NOT meant to be portable the same way as the rest of
APR!  This is a VERY important distinction.  These files are mean to
provide a method for programmers to get a file in their platforms native
type.  What they do with it at that point is up to them.  

BTW, the code I posted would break at compile time for ANY non-int socket
type.

ap_file_os_t is defined in apr_portable.h to be whatever is appropriate
for each platform.  Write is a POSIX call.  If int is not appropriate for
your system, and you didn't #define SEND to be something other than write,
then this WILL break at compile time.  If it doesn't, you have a broken
pre-processor, because it isn't substituting in the defined types.

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