Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: Using vfork() -vs fork() Message-ID: <2368@auspex.auspex.com> Date: 17 Aug 89 18:24:59 GMT References: <1989Jun19.013230.16107@marob.masa.com> Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 67 >Pertaining to vfork() and fork() usage in Berkely-specific C programs: > >From what I can glean from the manual, the advantages of vfork() over >fork() are (1) virtual memory efficiency and (2) shared access to parent >memory, data structures, etc. until an execv(). Uhh, 2) isn't supposed to be thought of as an advantage - it's supposed to be thought of as a consequence of the current implementation, subject to change at any time. I.e., don't *rely* on this behavior, for, as the vfork man page says: BUGS This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of "vfork" as it will, in that case, be made synonymous to "fork". >The disadvantage seems to be that returning to the parent context while >the childs context still exists does not work. Does this mean that >spawning an asynchronous process via vfork() is not possible? Unless the asynchronous process is going to be running a different program - i.e., it's going to do an "exec" - yes. "vfork" was specifically intended to be used when the subprocess was going to do a few things - things like shuffle file descriptors, change current directory, etc. - and then "exec". None of those things should modify any global data structures whatsoever, except for those in the kernel/U area.... >My application wants to spawn children to: >(1) execute adhoc subtasks (like `system("command")' ). >(2) execute adhoc subtasks asynchronously (like `system("command &")' ). >(3) execute cooperative subtasks for data sharing (like `popen("command")' ). > >My feeling is that vfork() is less appropo for this application than >fork(). Am I offbase about this? If in the "like ..." examples you mean the child process really will do the equivalent of that - which means doing an "exec" of the program in question - "vfork()" is appropriate. If you mean that the child will be running the *same* code as the parent - and not simply by virtue of doing an "exec" of the same program - "vfork()" is completely inappropriate. >Can someone provide concrete examples of where I'd want to use vfork(), >rather than fork()? 1) The "system()" library routine could use it, since it just "exec"s "/bin/sh" after the "vfork()". (In fact, in 4.xBSD, it *does* use "vfork()".) 2) The "popen()" library routine could use it, since it just shuffles file descriptors and "exec"s "/bin/sh". (In fact, in 4.xBSD, it *does* use "vfork()".) 3) Shells can often use it, since they shuffle file descriptors, etc. and then "exec" the command. If the command is a script in their own language, though, and they're going to execute the script by e.g. jumping back to their main command-interpretation loop (which is basically what the Bourne shell does if the "exec" fails with ENOEXEC - if the file has a "#!" line, the "exec" succeeds because it fires up a new "/bin/sh"), they can't use it, though, since the child process will still be running the same program. 4) "make" can use it, since it just "exec"s the program or "/bin/sh". 5) Etc..