[kelnos]

Forking is one of those things that is a super elegant solution when things are simple, but breaks down when things become complicated.

Multithreaded app? Fork is now a liability, and is only useful if the only (more or less) thing you do in the child is exec. Might as well only have Windows-style CreateProcess at that point.

For single-threaded programs, sure, fork is fine and gives you more flexibility than a CreateProcess-type API.

Asynchronous signals have a lot of the same problems, but those problems are also present in single-threaded programs. Quite a few APIs have been added over time to try to make working with async signals easier and safer, but all of them add their own new gotchas.

[jolmg]

> Asynchronous signals have a lot of the same problems, but those problems are also present in single-threaded programs. Quite a few APIs have been added over time to try to make working with async signals easier and safer, but all of them add their own new gotchas.

Isn't this referring to uses beyond what async signals are good for, or are you saying that async signals should just not exist in favor of something else? It's not like they're meant to be the only IPC mechanism, but they're good as a standard way to inform a process of certain things while having default handlers.

EDIT: Nevermind.

[somat]

so... shitpost warning but...

Perhaps forking is the elegant refined mechanism and multi threading is the abomination that should have never been invented.

Multithreading is the concept that a process(an independent execution unit) can share memory space with another process. and it turns out you can, only at the cost of making all your memory access methods extremely fragile and error prone. The concept should have never been invented.

[renox]

Sharing an address space was the default until the MMU was invented. That said I agree with you that multiple process with some optional shared memory seems to be a much safer approach than the share by default multithreading I don't know why MT won..