321–330 of 358 posts
Earlier quoted context omitted.
The value is not needing to change every other syscall and not needing to write new ones with a pid argument (besides which, what when you want to change it to a pidfd argument? then you add pidfd_syscall instead of duplicating every syscall again)
I meant the value of running syscalls in another process from the parent process in contrast to (v)forking and running them in the child directly.
Earlier quoted context omitted.
> being able to inexpensively spawn a carefully tailored process regardless of the size and scope of the current process would be better. It's called clone(2)
Which argument to clone starts the process with an empty address space?
Earlier quoted context omitted.
It’s a hack with many disadvantages. Sometimes a hack is the right answer, but the kernel should it add a primitive for it.
Should bash link in every program the user might want? Load them up as dynamic libraries?
Bash as a programming language is just a bad idea.
Earlier quoted context omitted.
Spawning processes should not be on the hot path of any program.
It ends up on the hot path of programs that use process isolation aggressively
Earlier quoted context omitted.
Fork is conceptually simple. Without bringing in any other layers, you start a process with the one thing known to exist: yourself. Otherwise you need multiple steps to create a process, fill it with something to run, and arrange for it to execute. Or like Win32 you permanently smush them together with other layers, like filesystems and object loaders and linkers.
It's not conceptually simple. No other object creation API works by copying an existing thing and then modifying it. You don't create a new file by copying an existing one and then modifying it. You don't create a new window by copying an existing one and modifying it. Attempting to justify clone/exec as a reasonable design is just Stockholm syndrome.
Clone-and-modify is pretty common in CAD.
> You don't create a new file by copying an existing one and then modifying it.
Clone-and-modify is almost universal in version control systems.
Earlier quoted context omitted.
It's not conceptually simple. No other object creation API works by copying an existing thing and then modifying it. You don't create a new file by copying an existing one and then modifying it. You don't create a new window by copying an existing one and modifying it. Attempting to justify clone/exec as a reasonable design is just Stockholm syndrome.
> No other object creation API works by copying an existing thing and then modifying it. Clone-and-modify is pretty common in CAD. > You don't create a new file by copying an existing one and then modifying it. Clone-and-modify is almost universal in version control systems.
It's closer to copy-on-write. Also, it actually makes sense there because in 99.999% of cases a commit actually is a modified copy of its parent. That isn't true for process spawning.