Message-Id: <m10XV4a-000S7QC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>, djgpp-workers AT delorie DOT com
Date: Wed, 14 Apr 1999 16:16:13 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Stack in djgpp
In-reply-to: <199904141839.OAA10062@mccoy2.ECE.McGill.CA>
References: <m10XR79-000S8IC AT inti DOT gov DOT ar> from "Salvador Eduardo Tropea" at Apr 14, 99 12:02:36 pm
X-mailer: Pegasus Mail for Windows (v2.54)
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca> asked:
> Bonjour M. Salvador Eduardo Tropea
> 
> > Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de> replied:
> > > On Tue, 13 Apr 1999, Salvador Eduardo Tropea (SET) wrote:
> > > 
> > > > 1) fork(), the author uses fork just because the command is there, he forks, 
> > > > one thread execs another program and the other waits! why? isn't that the 
> > > > same that spawn(P_WAIT,... ?
> > > 
> 
> Why do you have the impression that the others are waiting ? Are they block
> on mutexes or something ?  Un*x is a full mutitasking OS fork()ing and 
> exec()ing is well know paradigm.

Simply the code *calls* wait! why? because the ouptup of the child is needed 
to continue (is an stage of the compiler).
 
> > > Answer in a nutshell: there *is* no 'spawn' on Unix (including Linux).
> > > spawn and friends are a DOSism.
> > 
> > Ok, so what's the best in this case:
> > 1) Add conditional compilation stuff (makes the code harder to understand)
> > 2) Implement spawn and make it conditional (taked from libc in DOS or the 
> > emulation under Linux).
> 
> Implementing fork(), on a single-task OS, with stubs will not gain
> you anything especially if the processes are communicating via IPC.

I told the father is waiting, no IPC, no real multitask.

> Eli proposed and idea to use system("start /m.. ") and depending on
> the amount of code you do before the exec .i.e dup2() etc ..
> this may not even be possible.

I was in this thread, and it doesn't help on DOS, so isn't really usefull.

> > > > 2) The author also does it:
> > > > 
> > > >     yyin = fopen(preOutName,"r");
> > > >     unlink (preOutName); 
> > > >     if (yyin == NULL) {
> > > > 
> > > > What's that?! he opens the file and unlinks it. Is that supposed to work in 
> > > > UNIX? I mean: what the program will get from a file that was unliked?
> > > 
> > > A temporary file that doesn't leave any trace of its existence in the file
> > > system (unlink deletes only the directory entry, if the inode, i.e. the
> > > file itself is still used by someone).  Among other tricks, this means
> > > that no other program will have an opportunity to access that same file,
> > > whether by accident or on purpose. 
> > 
> > Looks like it was accident, so then UNIX will release the space when the file 
> > is closed?
> 
> This is no accident but common use.  

The author told me he didn't want to do it.

> I/O handles are serialize within the 
> kernel with reference count.  Until that ref. goes to zero the file is
> not actually deleted.  The file will be deleted until the las t process
> close it.  The kernel will maintain consistency.
> 
> > Should djgpp behave like this. I mean: unlink checks in the list of opened 
> > files, if the file is open it just sets a flag (not call) and then in close 
> > check this flag and if needed remove the file... hmmm can be implemented, 
> > don't know if that's really needed.
> 
> You mean some sort of reference count.  This will not work if you
> don't have support from the OS.

It will work, but not 100% equal, at least the file will be removed. In Win95 
the unlink of an opened file fails so doing what I say the file will be 
deleted and the program will work. In DOS there is no solution.

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://welcome.to/SetSoft
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(5411) 4759 0013