4 ms·
I've wondered if process creation on Unix could be overhauled by extending some of the existing syscalls to operate on a separate process rather than the curren
by boricj 3y ago
I've wondered if process creation on Unix could be overhauled by extending some of the existing syscalls to operate on a separate process rather than the current one:
// dup2() a file descriptor to the destination process
int rdup2(int procfd, int oldfd, int newfd);
// mmap() at the destination process address space
void *rmmap(int procfd, void *addr, size_t length,
int prot, int flags, int fd, off_t offset);
// create a thread remotely
int rpthread_create(int procfd, pthread_t *restrict thread,
const pthread_attr_t *restrict attr,
void *(*start_routine)(void *), void *restrict arg);
...
With this model, creating a new process would start by creating an empty, suspended one, then populating the various pieces with the returned process file descriptor:
* file descriptor table,
* address space,
* stack,
* threads...
Once everything's in place, the process would be unsuspended with one final syscall and start execution.
- saurik 3y agoWelcome to mach!
- Joker_vD 3y agoYou mean, like DuplicateHandle, MapViewOfFile2, and CreateThreadRemote from Win32 API? Well, to be fair, it has some merit: UNIX processes are possibly the only resources/kernel objects across any existing OS that can be created only by copying an existing one and then fiddling with the copy to make it look right. That's quirky. And if we have "procfd"s, then the need for process 1 (and the rules about a parent process having to call wait() for its children) goes away, just like on Windows: if the parent P of a would-be zombie process Z closed the procfd of Z, then when Z terminates the refcount of its process entry in the process table drops to zero and it gets cleaned up, freeing the Z's globally-visible PID, along with other B's resources like disk files and sockets, without P having to do anything.
- boricj 3y agoI was actually inspired by the Zircon system calls from Fuchsia, which is a capability-based system. Operating on the current process or another one is just a matter of passing the correct handle to the relevant system calls. I'm not familiar with the Win32 API, but I'm not surprised to learn that it has similar facilities (although MapViewOfFile2 appears to be a fairly recent addition). I'm of the opinion that POSIX is a fossilized design kept on life support, no longer fit for purpose in the modern era. Modern Unix-like are trying to plug in the holes with mostly proprietary extensions and this proposal would be just another one added to the pile... Whatever the future is made of, I do hope we won't have to carry 50 years old design mistakes for another 50 years from now.
- amelius 3y agoAre there any good public resources on the design of Fuchsia?
- boricj 3y agoFuchsia's getting started documentation can be found there: https://fuchsia.dev/fuchsia-src/get-started/learn https://fuchsia.dev/fuchsia-src/get-started/learn If you want to drill down a specific topic, you can look at the concepts section there: https://fuchsia.dev/fuchsia-src/concepts https://fuchsia.dev/fuchsia-src/concepts
- deleted 3y ago[deleted]
- the8472 3y agoexisting: process_vm_readv, pidfd_getfd; proposed: io_uring_spawn https://lwn.net/Articles/908268/ https://lwn.net/Articles/908268/ https://lpc.events/event/16/contributions/1213/attachments/1012/1945/io-uring-spawn.pdf https://lpc.events/event/16/contributions/1213/attachments/1...
- Ericson2314 3y agoYes, that sounds like exactly what I was thinking! It's just incredibly better.