3 ms·
From "Operating Systems: Three Easy Pieces" chapter on "Process API" (section 5.4 "Why? Motivating The API") [1]: ... the separation of fork() and exec() i
by khaledh 5y ago
From "Operating Systems: Three Easy Pieces" chapter on "Process API" (section 5.4 "Why? Motivating The API") [1]:
... the separation of fork() and exec() is essential in building a UNIX shell,
because it lets the shell run code after the call to fork() but before the call
to exec(); this code can alter the environment of the about-to-be-run program,
and thus enables a variety of interesting features to be readily built.
...
The separation of fork() and exec() allows the shell to do a whole bunch of
useful things rather easily. For example:
prompt> wc p3.c > newfile.txt
In the example above, the output of the program wc is redirected into the output
file newfile.txt (the greater-than sign is how said redirection is indicated).
The way the shell accomplishes this task is quite simple: when the child is
created, before calling exec(), the shell closes standard output and opens the
file newfile.txt. By doing so, any output from the soon-to-be-running program wc
are sent to the file instead of the screen.
[1] https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-api.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-api.pdf
- R0b0t1 5y agoThis is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.
- bollu 5y agoI'd like a reference for this explanation :)
- saurik 5y agoThese things are possible with APIs like CreateProcess or posix_spawn, but involve the API ending up with a million little customizable parameters in the attempt to simulate all of the behaviors that can trivially be implemented if you just support "let me run some code in the target process before I replace its memory"... which is like, exactly why "easier to implement" sort of means: something is often easier to implement if it is a single universal and general primitive that forms an elegant solution to a wide set of problems rather than being a myriad collection of hacks for various use cases. As an API--particularly on systems with copy-on-write pages--fork is amazing.
- deleted 5y ago[deleted]
- pjc50 5y agoRunning code in the target process space before the target executable is loaded is not possible with CreateProcess. Configuration of the target process has to be done by the operating system, via an ever-growing list of attributes you can pack into STARTUPINFOEX. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute https://docs.microsoft.com/en-us/windows/win32/api/processth... UNIX fork/exec is also significantly faster than CreateProcess, but I'm not sure how much of that is necessary rather than contingent, or results of an ever growing list of "security" programs insisting on a veto. https://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux https://stackoverflow.com/questions/47845/why-is-creating-a-... Fork+IPC architecture - effectively multithreading but where the processes don't automatically share memory and can crash separately - also requires fork(). However this has very much fallen out of fashion. () I suppose you can emulate fork by calling CreateProcess with an empty executable and CREATE_SUSPENDED, then use various debug APIs to overwrite its memory map with your own, but this is very messy.
- R0b0t1 5y agoI know, but running code in the target's process space isn't necessarily required nor does the API need to take on an amazing slew of options. That the NT API did is merely indicative of its growth, not an indication that fork is the one true way.