Mail Archives: djgpp-workers/1998/03/09/05:41:19
Eli Zaretskii wrote:
>
> On Mon, 9 Mar 1998, Vik Heyndrickx wrote:
>
> > DOS has a function that creates a temporary file, why cannot we use that
> > for tmpfile?
>
> Because it is not flexible enough: you cannot open the temporary file
> with DENY_ALL sharing property
You are right that you cannot get full access control, but is that
necessary?
In which sharing mode would such a file be opened by default? The most
sensible mode precisely seems DENY_ALL, but I'll need to test that. The
importance for being able to open a file in a particular sharing mode
seems low.
> , and you cannot control the name DOS
> creates (it's not needed for `tmpfile', but *is* needed for `mkstemp')
But not for tmpfile :-)
> and the place where DOS puts it (we want it to go to $TMPDIR, for
> example).
IIRC this can be controlled through the DOS call.
> > tmpfile is one aspect, the other functions that require a name to be
> > returned instead of a file descriptor (handle) still have to cope with
> > this kind of problems.
>
> This problem always exists, AFAIK you can't do anything about it unless
> you actually open the file when you create the name (and leak file
> handles).
The problem will indeed always exist, but the chances that a name
collision occurs with our current implementation is almost 100% when you
have two processes running long enough at the same time. The method I
describe decrease this chance to nearly 0%
Since it is impossible to solve the problem perfectly, it seems a
valuable alternative.
> > My idea is to provide a name for those functions based upon at least:
> > - a process ID (preferably r/m PSP address) 2^16
>
> Won't all first-level programs in different DOS boxes on Windows have the
> same PSP address?
I though the DOS conventional memory was common to all DOS boxes, or am
I so wrong?
If you are right, what about getpid()?
> > This resolution is enough to assert that:
> > - no same filenames are produced by different processes
>
> Not if the PSP problem above exists. You would need the VM id to cover
> for this.
>
> > - no same filenames are produced in one day
>
> What would stop two programs to start on the same second in two different
> DOS boxes? E.g., imagine two Make's running in two different DOS boxes:
> they can easily launch GCC with less than 1 sec between them (on a fast
> machine).
This remark belongs to the point above, with a different PID this could
not occur.
BTW, The filename creation function would still check whether the
filename belongs to an existing file before returning it to the user.
> > Another problem, what should MAX_TEMPNAM (I'm not sure about this name,
> > but you should know what I mean) in one of the header files be like? The
> > value of X?
>
> AFAIK, this is the max number of unique names we can *potentially*
> generate.
Meaning, in the example above 86400 * X ?
--
\ Vik /-_-_-_-_-_-_/
\___/ Heyndrickx /
\ /-_-_-_-_-_-_/
- Raw text -