4 ms·

> Instead of engineering around this (lazy loading services, fixing things, not doing things nobody needs) they had the great idea they could start the editor o

by sedachv 10y ago

> Instead of engineering around this (lazy loading services, fixing things, not doing things nobody needs) they had the great idea they could start the editor once and then core dump the in-memory state of a running editor. Then on later editor starts they would map-in the core dump and instantly be in a (somewhat) good state. Fails all kinds of smell tests and really speaks to bad taste having unbounded consequences. How else would you compile a dynamic programming language program into a binary executable?

sedachv 10y ago
BTW, something that just came to mind: this "bad taste having unbounded consequences" of copying the entire process memory is exactly how fork(2) works.
- 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 ago
    Nothing 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).

by sedachv 10y ago

sedachv 10y ago

BTW, something that just came to mind: this "bad taste having unbounded consequences" of copying the entire process memory is exactly how fork(2) works.

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 ago
  Nothing 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).