Mail Archives: djgpp-workers/1998/03/09/10:28:22
Eli Zaretskii wrote:
> On Mon, 9 Mar 1998, Vik Heyndrickx wrote:
> > What other program could want to open our file for writing?
> Another DJGPP program which calls `tmpfile' at the same time.
Nope, DOS returns a different filename to the other prg. I'm quite sure
they got this right because it is essentially the reason why a function
like this exists within DOS.
> 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 chances this happens is extremely low AND also existant with YOUR
modified function.
The only way no problems will arise is with both programs being aware
that other programs may be running at the same time.
> > 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).
Hmmm.
Now that a really appropriate reason has been found to use the LFN->SFN
variety of that DOS function call, you don't like it :-(
> > 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.
It was this I was not sure about (any more).
> 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.
This all makes sense when both physical address spaces are different.
Just to make very sure I understand it right, two DOS programs in a
different box cannot use the conventional memory area to pass data to
each other?
> > > 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.
Can we get at our TSS somehow?
It may even suit my interest better since it has only 13 bits defining
its unicity instead of 16.
BTW, it is a general rule NEVER to rely on the speed of the machine when
it concerns multitasking, concurrancy and mutual exclusion and other
fancy things like that. In this light 18.2 is 18.2 times better than 1s,
but it remains bad, and becomes worse when computers get faster (a
8099986 running at 1GHz).
The value of getpid () somehow is not entirely distinct from the current
time, so it seems a bad candidate in the first place.
> `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.
It is NOT incorrect, since it defines only a lower bound. Question is
what is more appropriate. We could even set TMP_MAX as small as 25
without breaking ANSI complianceness.
> 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?
No. I can squeeze about 39^8 different names within 8 positions (without
touching the extension)(needs re-checking on my part) . I set X just to
the maximum possible value computed out of the other parameters, which
was about 800 last time I checked this.
I find this values actually relatively low, but not unacceptably low.
--
\ Vik /-_-_-_-_-_-_/
\___/ Heyndrickx /
\ /-_-_-_-_-_-_/
- Raw text -