srg@quick.COM (Spencer Garrett) (09/28/87)
In article <7672@felix.UUCP>, preston@felix.UUCP (Preston Bannister) writes: } In article <838@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: } } >There is one thing about UNIX fork()-exec() that you've overlooked -- } >after the fork(), the child process can set up the environment of the } >soon-to-be-exec'ed process by modifying its own environment. } >(Can you say `pipes, I/O redirection and current directory'? } >I knew you could.) } } What I should have said :-) was that the } code executed between the fork() and exec() call typically does not } need the full semantics of fork(). Indeed it does not. That's why Berkeley has vfork(). A vfork call "borrows" the parent's memory instead of copying it. The parent is kept in suspended animation while the child modifies the new environment. When the child exec's (or exit's) the memory is given back to the parent instead of being freed.
kent@tifsie.UUCP (Russell Kent) (09/30/87)
in article <125@quick.COM>, srg@quick.COM (Spencer Garrett) says: > Xref: tifsil comp.arch:734 comp.unix.wizards:1187 comp.os.minix:494 > > In article <7672@felix.UUCP>, preston@felix.UUCP (Preston Bannister) writes: > } What I should have said :-) was that the > } code executed between the fork() and exec() call typically does not > } need the full semantics of fork(). > > Indeed it does not. That's why Berkeley has vfork(). A vfork call > "borrows" the parent's memory instead of copying it. This (perhaps unfortunately) includes the information about open FILEs and file descriptors, which precludes the redirection of the child's streams without a good deal of work by the parent to recover. Preston's objections to the fork()/exec() concepts are valid; they glob together concepts which should have been kept separate. Unfortunately, the inertia of all those programs running already will probably preclude us from re-defining the process startup primitives. An alternative solution to the problem of poor performance during the fork() is to use a copy-on-write algorithm which gradually duplicates the parent's address space as the parent or child attempts to change values. (Can you say real MMU? :-) -- Russell Kent Phone: +1 214 995 3501 Texas Instruments - MS 3635 Net mail: P.O. Box 655012 ...!{ihnp4,uiucdcs}!convex!smu!tifsie!kent Dallas, TX 75265 ...!ut-sally!im4u!ti-csl!tifsie!kent