3 ms·
Doing something that relies on OS internals is bad taste when done in userspace. Interface stability aside, what fork does is simpler: a copied process can rel
by firethief 10y ago
Doing something that relies on OS internals is bad taste when done in userspace.
Interface stability aside, what fork does is simpler: a copied process can rely on its environment matching its parent's enough for a large subset of the contents of the duplicated address space to retain their meaning. Serializing a process's address space's contents and then loading it into an "unrelated" process later makes it more complicated to know what memory contents can still be relied on (e.g. ASLR, file handles, etc.).
- armitron 10y agoNothing of what Emacs or Common Lisp systems or Smalltalk systems do when they dump images relies on OS internals. Emacs unexec relied on glibc internals but the new portable dumper does away with that and only relies on gasp Emacs internals. Where do you people come up with that stuff?
- sedachv 10y ago> Interface stability aside, what fork does is simpler: a copied process can rely on its environment matching its parent's enough for a large subset of the contents of the duplicated address space to retain their meaning. Serializing a process's address space's contents and then loading it into an "unrelated" process later makes it more complicated to know what memory contents can still be relied on (e.g. ASLR, file handles, etc.). Everything you mentioned except for ASLR is a problem for forked processes, and it boils down to kernel state (file descriptors and signals being two that I can think of right now).