From: Alain Magloire Message-Id: <199904141839.OAA10062@mccoy2.ECE.McGill.CA> Subject: Re: Stack in djgpp To: djgpp-workers AT delorie DOT com Date: Wed, 14 Apr 1999 14:39:44 -0400 (EDT) In-Reply-To: from "Salvador Eduardo Tropea" at Apr 14, 99 12:02:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Bonjour M. Salvador Eduardo Tropea > Hans-Bernhard Broeker 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 !!!