A better analogy is that continuations are reified function call return addresses, since return addresses come with a frame pointer (explicit or implicit), and therefore are closure-like.

Sure, they have MEs that maybe you can't disable, but you can firewall them.

Server kit is just not like consumer kit. Even laptops are [still, for now] a lot better than smartphones in this regard.

The real restrictions are:

  - you can't damage the function call frame
    of the caller of vfork(), thus you can't
    return from it

  - you may only call async-signal-safe
    functions on the child side of vfork()

There is a ton of vfork()-using code that adheres to these real restrictions and has been working fine for decades. That includes several posix_spawn() implementations, the C shell, etc.

I demand evidence that this part: "the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork()" is remotely true. That evidence must be of the form of bug reports that were accepted and which stand to scrutiny.

I've never found any such evidence. Have you?

Meanwhile I have a proof by existence that vfork() is safe used much more liberally than you say it may be used.

> You can't use local variables, or call any functions other than _exit or execve.

There are other async-signal-safe functions, and they get used routinely by posix_spawn() and other code to do child-side setup before execve(2), including: I/O redirection, process group setup, signal handling changes, etc.

I've no idea about that and I won't opine. But every time I see that sort of statement it seems likely motivated by the whole Twitter acquisition. Perhaps that was just a toy or vanity project for him, one he could afford, so even if you think he's running X terribly it might have nothing to do with how he's run or would run any other companies that are not related to social media. In other words, what I read into such statements is "I don't like the politics he's brought to Twitter!", "the board should rein in the guy whose politics I don't like!!". It's like saying Bezos is bad at business because he owns the Washington Post -another vanity project- and you don't like the Post.

Do people not get bored of that sort of take?

Tell me he makes bad business decisions all you want, but in the context of everyone-hates-his-acquisition-of-Twitter I'd like to hear about his other businesses. Tell me something useful, not something political.

And, sure, politics at some point bleeds into business. Maybe Trump is out to get Bezos over Washington Post coverage, or maybe the next Democrat President will go after Musk for his politics. It's possible that X will eventually cost him dearly and personally, and it's a solid argument for these billionaires and trillionaires to stay out of politics. Or maybe it's a good argument for them to stay in because maybe by demonstrating electoral influence and power they can make the POTUS-of-the-day fear them enough to not go after them too hard. But if you made any such argument it still wouldn't say tell me anything about the rest of these billionaires' businesses.

FINALLY!

I like this design.

And yes, the community resisted this for way too long.

> No, it was done that way so that you could launch a program that was too big to fit in memory with the parent program.

Ironically vfork() is even better in this regard. I wish Unix had only ever had vfork().

POSIX says nothing much about vfork() anymore. It was a mistake removing it. Zealots failed to understand that vfork() >> fork(). https://news.ycombinator.com/item?id=30502392

vfork() does NOT stop the world in many / most implementations. The ones that do stop the world do it because someone misunderstood the whole "vfork() stops the parent process" -- yes, it stops the parent process in a pre-threads world, but it doesn't have to stop any other threads but the one that called vfork(). Indeed, many implementations don't do that.

(Someone once tried to make NetBSD's vfork() stop the world because that's what the pre-threading man page said it does. I did my utter best to keep that from happening at the time, and it didn't then. Hopefully no one tried again later.)

Though I want a posix_spawn-as-a-system-call approach as well / instead of that.