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 09:14:55 GMT
On Sun, 11 Apr 1999 02:54:14 -0500, Manoj Kasichainula wrote:

>On Sun, Apr 11, 1999 at 11:49:18AM +1000, Brian Havard wrote:
>> thisdir = apr_opendir("foo/bar");
>> if (thisdir) {
>>     while(apr_readdir(thisdir) == APR_SUCCESS) {
>>         printf("%s %d\n", thisdir->entryname, apr_dir_entry_size(thisdir));
>>     }
>> }
>
>Hmmm. This looks like it would require keeping thread-local data to
>keep track of where we are in a directory, or we wouldn't be allowed
>to share an ap_dir_t structure between threads.

You'd want to share a directory handle between threads? A regular unix
readdir() wouldn't do that! Surely you'd do an opendir in each thread.



>I really like the Java model for handling stuff like this. A directory
>is a list of directory entries. So, you have functions that can dump a
>whole list to an array.

Only problem there is that it's potentially wasteful to read the entire file
list. It could consume a large amount of memory if there a lots of files and
if you only use the first few entries, a lot of I/O as well.



>As another option, you have a token that is kept (the Iterator in
>Java) that keeps track of your position in the list. You then use an
>API call like "getNext(list, token)" that returns the next element in
>the list and advances your position as kept track of by the token. 
>
>Either or both of these options can be implemented (or many more, like
>a search_list() function).
>
>I think it's also good to keep a directory entry structure, and access
>things like name, size, etc, through a method interface to the
>structure. Now these methods could be #defines or inlines, but making
>it look like a function is good, because it hides implementation
>details and allows us implement lazy evaluation, behind-the-scenes
>caching, or whatever.

Yup, that's the sort of interface I like. Implementation detail hiding is a
good thing.

Hmmm, that brings to mind another possible optimization. Some OS's allow
filtering the file names returned. The interface could allow a filter to be
specified which would either be passed to the OS function or implemented in
the apr code where the OS doesn't support filtering.

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