<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 14, 2022 at 5:59 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/11/22 15:20, enh via Toybox wrote:<br>
> the toybox build is pretty noisy on a current mac, complaining that<br>
> vfork() should be replaced by fork() or posix_spawn().<br>
<br>
Sigh.<br>
<br>
> looks like it's because they've changed vfork() to just be fork() and<br>
> would like people to accept that they understand that by changing<br>
> their source to say fork() instead... (i'll copy & paste the man page<br>
> here because afaik apple doesn't give us anywhere to link to...)<br>
<br>
I.E. mac will never work on a nommu system. Got it.<br></blockquote><div><br></div><div>eh, makes sense to me ... i recently rejected patches for non-4KiB page sizes because there's no obvious path to shipping such a thing, so it's just untested code that will bitrot immediately. (exhibit A: "this isn't the first time someone's tried to clean up the hard-coded 4096es".)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>      The vfork system call can be used to create new processes. As of macOS<br>
>      12.0, this system call behaves identically to the fork(2) system call,<br>
>      except without calling any handlers registered with pthread_atfork(2).<br>
<br>
That's very much not what it's for. Apple hasn't got anybody left there who<br>
understands why it was there in the first place.<br></blockquote><div><br></div><div>for the systems macOS _does_ run on though, the "the fork() ... exec() model doesn't work great if you have lots of fds/page table entries/etc" problem is what they're more likely to be thinking about. linux added close_range() as a workaround for the fd problem, whereas Apple is (afaik) the only kernel that's actually implemented posix_spawn() as a system call. so they can theoretically at least -- i've never poked deeper -- do a better job than anyone else of avoiding unnecessary work when spawning. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(There are more nommu processors in the world than there are mmu processors.<br>
It's sort of a "total weight of all insects" vs "total weight of all mammals"<br>
thing. You just don't _notice_ them...)<br></blockquote><div><br></div><div>aye, but zero of them are running macOS :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>      This system call is deprecated. In a future release, it may begin to return<br>
>      errors in all cases, or may be removed entirely.  It is extremely strongly<br>
>      recommended to replace all uses with fork(2) or, ideally, posix_spawn(3).<br>
> <br>
> weirdly it looks like you can use _POSIX_C_SOURCE to make this go<br>
> away? from their unistd.h:<br>
> <br>
> #if !defined(_POSIX_C_SOURCE)<br>
> __deprecated_msg("Use posix_spawn or fork")<br>
> #endif<br>
> pid_t    vfork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;<br>
<br>
We can move that header into portability.h if we need to? It's #included before<br>
the rest for a reason...<br>
<br>
> -Wno-deprecated-declarations in configure works too,<br>
<br>
I'm happy to wait for it to break and then fix it better then. :)<br></blockquote><div><br></div><div>ack.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> though their<br>
> threat to make vfork() always fail in a future release makes me<br>
> question whether that's such a good idea. (i haven't followed apple<br>
> closely enough to know whether there's any precedent for violent<br>
> breakage like that. i'm not sure why you wouldn't just remove the<br>
> symbol rather than replace it with an implementation that always<br>
> fails?)<br>
<br>
Ask Rich Felker with his insistence that fork() must always be there on nommu<br>
systems and return -EINVAL, and me patching it out with an #ifdef in my build<br>
script.<br>
<br>
Rob<br>
<br>
P.S. A few years ago I did a contract at a place that ported an old system from<br>
wince to Linux and ran an ~80-thread .net app under mono, and every time they<br>
forked from one of those threads it froze the whole app for 75 miliseconds while<br>
it copied all of its memory to the new process. (Because forking from a thread<br>
defeats copy on write, the kernel doesn't even TRY to track it and just copies<br>
everything, which involves locks.) Unfortunately something needed 4ms response<br>
time to avoid going "boing". The fix was to replace the fork() with a vfork()<br>
which only froze the ONE thread that called it (until it could do the rest of<br>
its setup and _exit() or exec() the new process). No big memory copy, thus no<br>
latency spike. On a system that had an MMU, and yet...<br></blockquote><div><br></div><div>yeah, i thought i'd already said (but didn't spot it in my quoted bits when replying) that i've seen the Android system health folks switching a few fork()s to vfork()s lately. i have no immediate plans to make vfork() == fork(). people manage to screw up enough with just fork() (or they get really "clever" and try to use clone() directly) that i don't think i'd save myself much of a headache that way.</div></div></div>