httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: apr_fileinfo_t is ___BOGUS___
Date Mon, 15 Jan 2001 16:56:02 GMT
ah ok this is the detail i wanted to hear, guess i should just have read
more messages.

i'm not sure that it was me that made this a public type, are you sure?

at any rate if you want to make it completely private i suppose that's ok.
another solution is to just break it up into its components.

inode, dev are very POSIX specific.  i'd look at what we use them for --
i'm guessing they're only used for deciding if two files are the same file
or different.  as such it'd be better to have a platform specific opaque
type which performs that task.  perhaps there's something faster than
inode/dev on win32.  this could be used as part of ETag for example.

user/group/protection are clearly specific to POSIX type of access
control, which if i recall correctly is poorly emulated on windows
anyhow... and it'd be better to have a platform independant version of
these as well.

about the only thing which seems portable are size, mtime, and filetype
(at least for some values of filetype).  these are also incidentally the
only thing which the apache core requires... and the only ones i care
about their performance :)

anyhow i remove the veto, thanks for the extra info.  the easy solution is
a private type, but i'd prefer to see something of the above... but since
i ain't stepping forward with code don't let that set you back.


On Wed, 10 Jan 2001, William A. Rowe, Jr. wrote:

> Ok guys...
>   apr_fileinfo_t must be restored to an incomplete type.
> On win32, we have the following scenario;
>   inode, dev, and ctype require a CreateFile call.
>   type (pipe, etc) requires CreateFile/GetFileType calls.
>   query owner/access kills performance by two orders of magnitude.
>   truename requires a FindFile call.
> Now, there is no SINGLE ATOMIC CALL that does all this work for
> us.  It -should- be our problem (the win32 hackers) to get this
> right, but we can only do that with accessor functions.
> The changes need to also augment the lstat flavor, so that the
> one can be queried from the other (a significant performance
> boost on win32.)
> So if you disagree, scream.  If you don't like the call/return
> issues, consider that 'transparent' types ought to someday grow
> inline performance optimizations.  That's a seperate topic for
> another day.
> BTW - we also need an optimized form of apr_file_open that accepts
> an apr_fileinfo_t ... that handle we grabbed to stat the file can
> be Duplicated into a read or read/write handle for file access!  The
> file handle in the win32 flavor will be cached with a registered
> cleanup against the pool, so until we are destroyed, we can keep
> grabbing the file for different flavors of access.
> Bill

View raw message