Mail Archives: djgpp-workers/1999/04/14/14:40:30
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.
> > 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.
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.
>
> > > 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. 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.
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- Raw text -