Mail Archives: cygwin/1997/04/11/21:51:35
> Sorry, sent that out in a rush and didn't include some
> further explanation. I was referring more to the checking
> of existence of c:/tmp. This inevitably leads to checking
> of a failed open(), stat(), etc system calls that invoke
> disk operations.
So, what's wrong with checking the return codes from these? Certainly open()
and stat() could fail for any number of reasons, and it would be most useful
to tell the user what the reason is rather than go ahead an proceed and maybe
tell the user at some point that there is something mysterious wrong but by
that point the real cause is hard to determine. This sort of thing is
what ends up with programs that report that there was a problem and that
perhaps the disk is full when in fact a filename was mis-typed or a
directory is missing...
> I dunno how the getenv() argument was brought
> in but maybe we're just talking about different things.
I think that the original suggestion was to check for an environment variable
that would specify what directory to use for temp files. This could be set
to /tmp, /temp, or whatever.
> Those checkings probably do take a coupla of microseconds
> on average. In contemporary PCs, assuming an average of 2 cycles per
> instruction, a 166MHz pentium can execute about 250 instructions
> in 3 microseconds. In an application that does creation/destruction
> of temp files all the time or for every transaction, it is
> just not something that one would say is elegant to be inserted
> into the loops.
Then do it the first time and cache the result. Keep a static pointer
to the name of the directory to use for building temp files in. If it is
NULL, spend a little time to figure out the right place and store a pointer
to the directory to use. Thereafter, it's just a quick check of the pointer
to bypass the work of figuring it out. (One must also be careful to lock
the updating of the pointer for multi-threaded use, of course).
marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -