Author gregory.p.smith
Recipients John Jones, alex, benjamin.peterson, dhduvall, gennad, gregory.p.smith, neologix
Date 2017-03-17.16:33:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I think someone wanting this will need to put forward a patch adding it to be reviewed and mulled over.  As Alex mentioned in msg22571 - exists as does the code Danek pointed at in the next comment.  try those.

I suggest someone who actively cares about a limited available process address space environment contribute this.  (ie: not your typical 64-bit system)

fork()+exec() does not cause significant memory allocation, only a brief ~doubling of mapped address space, with backing pages being the originals just marked copy on write, but never written to by the child. The exec undoes that mapping.

It is technically possible to cause the copy on writes to happen if you immediately write to a large amount of memory in the parent process after the fork has happened before the exec has, but that seems like a rare timing problem that could even be worked around by monitoring the forked child to see that the exec has occurred before continuing.
Date User Action Args
2017-03-17 16:33:16gregory.p.smithsetrecipients: + gregory.p.smith, benjamin.peterson, alex, dhduvall, neologix, gennad, John Jones
2017-03-17 16:33:16gregory.p.smithsetmessageid: <>
2017-03-17 16:33:15gregory.p.smithlinkissue20104 messages
2017-03-17 16:33:15gregory.p.smithcreate