Mail Archives: djgpp-workers/1999/04/14/15:13:08
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
- Raw text -