fork() is pretty evil, especially now that we have multi-threaded programs.
It would be pretty cool if you could spawn an empty process in a stopped state, and then poke at it from the parent for a bit (open up new file descriptors/etc) before causing it to exec a real subprocess.
Doing things that way would avoid all the memory accounting issues, the performance issue of copying the page table for no good reason, and the significant complication of not actually being allowed to do anything that's not async-signal-handler-safe between fork() and exec(). (And nearly nothing actually falls into that category!)
Posted Jul 29, 2012 13:26 UTC (Sun) by nix (subscriber, #2304)
[Link]
It would be pretty cool if you could spawn an empty process in a stopped state, and then poke at it from the parent for a bit (open up new file descriptors/etc) before causing it to exec a real subprocess.
You can do that with PTRACE_O_TRACEFORK or PTRACE_O_TRACEEXEC, but as with anything involving ptrace() there are so many tentacles that virtually any alternative is preferable.
The ups and downs of strlcpy()
Posted Jul 30, 2012 1:51 UTC (Mon) by foom (subscriber, #14868)
[Link]
Apparently not *any* alternative, or a new userspace API would have been merged upstream by now. :)
The ups and downs of strlcpy()
Posted Jul 30, 2012 8:46 UTC (Mon) by nix (subscriber, #2304)
[Link]
Yeah, true. But if ptrace() was something everyone had to use, a replacement would have been merged by now, because ptrace() is just so odious in so very many ways. (Though the improvements in recent kernels have been substantial, and in maybe as few as five to ten years I'll be able to rely on them enough to actually use them in real software, which these days means "meant to be portable between Linux distros, including the dinosaur-era RHELs too many people insist on running their bleeding-edge software on". sigh.)