-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spawn() family of calls #637
Comments
Except that we have pretty much nothing that could use it. I think vfork() would be a better option and that is on my longer term list. The posix_spawn functions can then be written to use vfork(). I'd happily take an implementation for libc of posix_spawn* that used fork() for now so we have it ready for vfork() in future and people can use it. |
The problem is we do not have COW pages on Z80 and 6502, each fork is a complete time-consuming copy of previous process. |
Once we get a vfork() it won't copy. See the documentation for vfork on classic unix |
A bit late, but would this be level 1, 2 or 3? |
It's kind of irrelevant at this point as there is no use case and nobody needs it or has bothered to provide an implementation in the past 5 years nor anything that needs it. The 8bit ports can't support it for various architectural reasons, the 68K copies only a few Kb and fast so it's mostly a non-issue and the ESP8266 and modern small risc chips fork /bin/sh in almost no time as it's a mere 32K which for a modern fast risc chip doesn't take any time |
@erkinalp: |
@bscottm Yes, but the need for |
@erkinalp: Didn't say anything about |
No, what I mean is definitely a posix_spawn() that does not fork under the hood, but rather create a fresh process descriptor in a manner similar to Windows NT's CreateProcess() and then exec() to it. |
@erkinalp: |
To be more accurate programs then got enormously bloated and vfork became relevant again. In the Fuzix case the only cases vfork looks useful are flat systems like 68K as it avoids a data copy on fork and switch, but nothing we have that forks copies much data (riscv and ns32k are a bit worse as the toolchains don't generate split code/data relocatable binaries- but riscv is fast and ns32k is more a tool chain problem) So no use case, and no use case means not used means buggy |
spawnve
which does not callfork
andexecve
under the hood will prevent unneeded copies.The text was updated successfully, but these errors were encountered: