Message-Id:	<199804270915.LAA57422@ieva06.lanet.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Mon, 27 Apr 1998 11:13:44 +0300
MIME-Version:	1.0
Subject:	Re: Patch to add target specific cleanup for gcc.c
CC:	djgpp-workers AT delorie DOT com
References:	<Pine DOT A32 DOT 3 DOT 91 DOT 980427094517 DOT 59036A-100000 AT ieva06 DOT lanet DOT lv>
In-reply-to:	<Pine.SUN.3.91.980427101032.22490H-100000@is>

Date sent:      	Mon, 27 Apr 1998 10:15:58 +0300 (IDT)
From:           	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:             	Andris Pavenis <pavenis AT lanet DOT lv>
Copies to:      	GCC bug reports <bug-gcc AT prep DOT ai DOT mit DOT edu>
Subject:        	Re: Patch to add target specific cleanup for gcc.c

> 
> On Mon, 27 Apr 1998, Andris Pavenis wrote:
> 
> > my idea was to 
> > create one more temporary file at startup 
> >    open ( ...  , O_CREAT+O_EXCL+O_RDWR , .., ),
> > close it, and delete it before exit to get workaround for 
> > possible conflict of temporary filenames in DJGPP port of gcc due to 
> > lack of PID that could be used to create names of temporary files.    
> 
> I thought GCC in the DJGPP version uses mktemp to generate unique names. 
> (Even if it doesn't, this is the right way, don't use PIDs.) If so, the
> version included in the next v2.02 of DJGPP library should solve the
> problem of file name clashes between temporary files.  If this is true,
> you could use the fixed version from the latest alpha release of DJGPP and
> avoid this additional file. 
> 
The source of problem is possible race condition between 2 copies of gcc
running in different DOS sessions. 

mktemp() only generates the name but file is not
actually created. The name after that is given to some other program for
example cc1.exe as name of object file to be generated. Unfortunatelly 
under Windows it is still possible for gcc from other DOS session to generate
the same name of temporary file. The probability of such conflict is less if
MKTEM__EACH_FILE is defined, but it is still big enough for us to ignore it.
(I got conflicts is tried to build 2 projects simultanously with MKTEMP_EACH_FILE
defined in gcc-2.8.1)

So I'm afraid possibility of conflict looks not avoidable in such way (for shared 
directory for temporary files) if we are not using some unique for process PID (or 
simulating it somehow as I suggested with one additional temporary file). 
 
My hack of mktemp() was one of possible workarounds for this problem. Of course
if such is used it must be documented.

> IMHO, there's no need to add application-level code which has substantial
> runtime penalty just to work around a bug in a library whose sources are
> freely available and which can therefore be easily fixed. 
> 
I would also like to avoid such hack. 

Andris

- Raw text -