5 ms·

fork() is not required for this. On Apple platforms the dyld shared cache performs the same function: all processes share the same copy of libSystem, Foundation

fork() is not required for this. On Apple platforms the dyld shared cache performs the same function: all processes share the same copy of libSystem, Foundation, etc.

nybble41 8y ago
Most platforms with dynamically-loaded shared libraries do something similar. However, that only avoids having multiple copies of the library code and read-only data in memory—each process still has to run its initialization code separately, parsing configuration files, setting up global variables, etc., and any data which is written during initialization but read-only for the rest of the program is not shared. The Zygote model allows the system to perform this initialization just once and share the results with any number of child processes. I believe the Apache web server's Prefork MPM module does something similar—fork() allows the server to spin up new child processes in a pre-initialized state, ready to respond to requests. Servers in general tend to be a good fit for this style of execution.
- geofft 8y ago
  So redesign your software to allow storing the results of initialization code having run, configuration files having been parsed, global variables having been set up, and so forth in a loadable library (or in some other mmappable file). Emacs works this way, because it has a lot of Lisp code to load in and compile and doesn't have a central daemon (and even if it did, it would want to avoid recompiling the code when the computer is rebooted.) The compiled C binary "temacs" is instructed to load and evaluate a bunch of Lisp and then more-or-less coredump itself in an orderly way to a binary called "emacs"; when that binary is run, everything is in memory as if you had forked temacs after initialization. https://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Emacs.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... For your average server process reading config files, it probably suffices to have a "compiled" form of the config files in Cap'n Proto or some similar format that is directly usable as in-memory structures, and mmap that in. (Or perhaps just actual native data structures, if the format doesn't need to have a stable representation across versions of your software.)

fork() is not required for this. On Apple platforms the dyld shared cache performs the same function: all processes share the same copy of libSystem, Foundation, etc.

nybble41 8y ago

Most platforms with dynamically-loaded shared libraries do something similar. However, that only avoids having multiple copies of the library code and read-only data in memory—each process still has to run its initialization code separately, parsing configuration files, setting up global variables, etc., and any data which is written during initialization but read-only for the rest of the program is not shared. The Zygote model allows the system to perform this initialization just once and share the results with any number of child processes. I believe the Apache web server's Prefork MPM module does something similar—fork() allows the server to spin up new child processes in a pre-initialized state, ready to respond to requests. Servers in general tend to be a good fit for this style of execution.

geofft 8y ago
So redesign your software to allow storing the results of initialization code having run, configuration files having been parsed, global variables having been set up, and so forth in a loadable library (or in some other mmappable file). Emacs works this way, because it has a lot of Lisp code to load in and compile and doesn't have a central daemon (and even if it did, it would want to avoid recompiling the code when the computer is rebooted.) The compiled C binary "temacs" is instructed to load and evaluate a bunch of Lisp and then more-or-less coredump itself in an orderly way to a binary called "emacs"; when that binary is run, everything is in memory as if you had forked temacs after initialization. https://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Emacs.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... For your average server process reading config files, it probably suffices to have a "compiled" form of the config files in Cap'n Proto or some similar format that is directly usable as in-memory structures, and mmap that in. (Or perhaps just actual native data structures, if the format doesn't need to have a stable representation across versions of your software.)