httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: cvs commit: apache-apr/include apr_file_io.h
Date Sun, 11 Apr 1999 01:49:18 GMT
On Sat, 10 Apr 1999 03:03:39 -0700, Greg Stein wrote:

>Brian Havard wrote:
>> On Sat, 10 Apr 1999 01:13:17 -0700, Greg Stein wrote:
>> ...
>> >Why can't the Apache version have a striking resemblance to Unix's
>> >"struct direct" ?
>> 
>> It doesn't have a striking resemblance to Unix's "struct direct", it IS
>> Unix's "struct direct" ...
>
>Sorry... forgot the smiley. "striking resemblance" was simply the
>innocent-bystander-thought ("gee! that structure looks a LOT like
>dirent!")

Yeah, I got that but the whole problem I had with it is the acutal use of the
unix type in the header.



>> and specifying it as such in a supposedly portable
>> header file is ugly. It will have to be #ifdef'd to something else on
>> platforms that don't have it.
>
>The #ifdef's must occur somewhere, but I'll grant you that loading up
>the header file with them may not be the best idea.

I think there'll need to be a 'private' section in the apr_dir_t that holds
platform specific data (yes, I'd usually do this sort of thing in a C++
class) and that area will be #ifdef'd. The public interface must be constant.



>> It doesn't necessarily have to be a new structure that just gets returned
>> instead. We already have a struct apr_dir_t. The information about the last
>> entry read could be made available via the pointer to it you already have.
>> 
>> The unix dirent is very limited in that it only contains the file name. Other
>> platforms (and probably other APIs in unix) provide more details like
>> date/time stamps, size, attributes etc. which could be made available, saving
>> an extra stat() type operation when it's wanted.
>
>Ah! Now we have a good reason to use a different structure :-)
>
>But now you have a problem:
>
>* if you define the structure to include, say, file size, then what do
>you do for the systems that don't have that? Do they need to issue a
>stat() on each file before returning? Oops. What if the caller didn't
>need that piece of information?

Yes indeed. No I don't suggest doing a stat() for every entry just in case.



>* if you leave it out of the structure, but somebody *does* want it,
>then you potentially throw away good information for those platforms
>that retrieved it easily.
>
>Solution? For the functions that return an apr_dirent_t (or inside
>apr_dir_t as you suggest), they should take a flag. The flag will state
>which pieces of information are needed by the client. APR will fill in
>that information with the appropriate call(s) to the OS.
>
>An alternative is to have flag bits in the structure that state which
>pieces are valid. However, this burdens all clients -- they must test
>the bit and pull the value from the structure or go ahead an make the OS
>call.

I think the best way is to retrieve the information via a function call like
apr_ssize_t apr_dir_entry_size(apr_dir_t *);

which will just return the information if available and if not, get it. In
the apr_dir_t's private area you have a struct stat or similar and a flag
which specifies if it's valid so if you query for size and then date only one
stat() gets done. The interface could look something like:

apr_dir_t *apr_opendir(const char *);
apr_status_t apr_closedir(apr_dir_t *);
apr_status_t apr_readdir(apr_dir_t *);
apr_ssize_t apr_dir_entry_size(apr_dir_t *);
apr_time_t apr_dir_entry_mtime(apr_dir_t *);
apr_status_t apr_rewinddir(apr_dir_t *);

Note no apr_dirent_t at all. It would be use like:

thisdir = apr_opendir("foo/bar");
if (thisdir) {
    while(apr_readdir(thisdir) == APR_SUCCESS) {
        printf("%s %d\n", thisdir->entryname, apr_dir_entry_size(thisdir));
    }
}


In the unix implementation the private area of apr_dir_t could contain a
struct dirent which the char *entryname element would point into so it would
be just as efficient as the current apr_readdir() if you just want the file
name.

--
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Mime
View raw message