>That is, the purpose of vfork() was to let you implement spawn(). (Prior >to Linux, no O/S even considered the "overcommit_memory" approach >because, let's face it, it's idiotic.)
Sort of. The vfork() call was added to 3BSD around 1980, while COW memory management was written for Mach in the late 1980s and wasn't merged into 4BSD until the mid 1990s. Like much of what Bill Joy added to Unix, vfork() was a hack. He noted that fork()/blah/exec() was a common idiom with a fairly small amount of blah, so he added vfork to handle that special case. It's still more general than spawn since the blah can be anything, not just whatever options spawn provides. Like every hack, it was quickly misused, often by the child process making changes to memory that the parent could see after the child's exec(). I wrote a history of COW a while ago: http://obvious.services.net/2011/01/history-of-copy-on-write-memory.html I would worry more about shared libraries with writable data pages that don't get copied when you fork. That's supposed to be a feature, to handle shared buffers for dbm style libraries, but wow, what a way to leak data. R's, John _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
