Message-Id:	<199804201720.TAA55456@ieva06.lanet.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	djgpp-workers AT delorie DOT com
Date:	Mon, 20 Apr 1998 19:18:31 +0300
MIME-Version:	1.0
Subject:	Temporary files for gcc-2.81

Hi!

DJGPP port of gcc-2.8.0 has rather nasty problem with names of files
generated by gcc.exe (gpp.exe) for temporary files. Currently in port
gcc-2.8.1 the situation looks slightly better:
   - after definition of MKTEMP_EACH_FILE compiler calls
     mktemp (template) for each temporary file instead of using one base
     name and appending number at it's end (so also going outside 8+3 limit)

I have not yet met problems with such version when I running gcc concurrently
from 2 DOS session under WIN95. However there still is place for problems as
mktemp() only checks for presence of file but does not create it. So  it's possible
for some other task still to get the same name for temporary file.

The best solution would be to implement some PID that would good enough.
I think we should not use any things that are sytem dependant (such as RDTSC,
that works on Pentium or better CPU's as we still have to handle also other 
systems). Also accessing PIT (8254) may not be available in all systems so we 
should exclude it. 

So I can mention some possiblities with my comments:
   -  _my_cs   - Is not usable under Win95. If I start 2 DOS sessions and 
      run the same program I'm getting the same value of _my_cs. At least 
      such are the results of my tests
   -  base address of _my_cs selector accessible through 
      __dpmi_get_segment_base_address(). Looks is Ok under Win95.
      Some checks under DOSEMU for Linux failed, but Linux totally crashed 
      shortly after that, when I tried to run 2 DOS sessions simultaneusly, so 
      maybe it is not supported. 
   -  reading time (biostime()). Perhaps this is only slightly better than nothing

Of course there are "surgical" methods such as creating file by mktemp() and 
closing it or creating temporary directory for each copy of gcc.exe. If we'll
use such methods we'll get some performance penalty.

I think I'll currently leave mktemp() from djdev201.zip intact. There perhaps 
is still some small possibility of conflicts but perhaps we'll can live with it
at least now. I repeat it really looks much better than available port of gcc-2.8.0

Andris

- Raw text -