Mail Archives: djgpp-workers/1998/03/09/11:37:33
On Mon, 9 Mar 1998, Vik Heyndrickx wrote:
> > It's another safeguard, that's all.
>
> What other program could want to open our file for writing?
Another DJGPP program which calls `tmpfile' at the same time. E.g.,
two compilations running in two different DOS boxes, or on two different
machines with the same shared temporary directory. One of the two
programs could be linked with an old version of the library which doesn't
care if the file already exists.
> The same I was referring to above, you pass a path and DOS appends the
> filename for the newly created temp-file.
Yes, but the problem is that there is no LFN cousin of that function, so
you cannot create files in directories with long names (and I didn't want
to enter the `_truename' mess to resolve this).
Oh, btw, I just looked closer at the latest release of the Interrupt
List, and it clearly says that 215A opens the file in compatibility mode.
> I don't understand "mapped into all DOS boxes" vs. "kept separate".
> Either any DOS program has a different "below 640Kb + UMB" address
> space, or it has the same.
> You imply the first?
There are physical addresses, and there are logical addresses. The first
1MB of every DOS box has the same logical addresses, but different
physical addresses. When Windows task-switches, it changes the page
directory so that the same logical address (e.g., the DOS PSP of the
running program) now points to a physically different address. So the
same PSP of COMMAND.COM now points to a different copy of COMMAND.COM in
each DOS box.
> PSP-segment IS unique?
No, they are definitely not unique. You can run a simple program that
calls the DOS GetPSP function in several DOS boxes and see for yourself.
Assuming that all DOS boxes are configured the same (i.e., you load the
same, if any, TSRs and device drivers, etc.), it will display exactly the
same PSP.
> > DJGPP's `getpid' doesn't use the PSP address. It reads the BIOS clock
> > tick count the first time it is invoked in the given program, then caches
> > the value and returns it hence.
>
> Then it most certainly not suits what I want as a unique value, since
> two programs can be started in the same 1/18.2s period.
It's better than once per second as you suggested. And if you have a
better way of getting a unique PID, please tell, as this issue (of unique
PID) bothers me a lot, with the proliferation of fast machines.
> X was the counter value (equivalent to the current counter in
> tempnam[e]). This value should prevent from different names to be
> generated during the same second by one program.
>
> Because a program cannot create more than X values during the same
> second I feel like setting MAX_TEMPNAM = X, but the program potentially
> can create 86400 * X in one day. That is why I am so careful about not
> setting it to 24 * 60 * 60 * X.
`tmpnam' is an ANSI function, and ANSI Standard rules as follows:
"The `tmpnam' function generates a different string each time it is
called, up to TMP_MAX times. If it is called more than TMP_MAX
times, the behavior is implementation-defined."
So it seems incorrect to set it to X, as nobody says that all TMP_MAX
calls are done in a tight loop. I read the above as a promise to have at
least TMP_MAX different names that can be produced.
(And in case you wonder what does this have to do with `tmpfile': AFAIK,
Posix specifically says that `tmpfile' calls `tmpnam'. At least most
Unix systems behave that way.)
> > And how do you account for the truncation to 8+3 namespace?
>
> I simply create filenames that ARE 8+3 (and don't contain '~' BTW), I
> don't know why I should make things more complicated?
No, I meant to ask how do you compensate TMP_MAX, since X*86400 is more
than you can squeeze into a 8+3, no?
- Raw text -