6 ms·

Can you please elaborate on why those two ideas are "horrible"? Forking processes seems like a rather elegant concept, to me. Granted, it's sometimes weird tha

by unwind 4y ago

Can you please elaborate on why those two ideas are "horrible"? Forking processes seems like a rather elegant concept, to me. Granted, it's sometimes weird that in order to have a process running image A create a process running image B, it must first have a mirror image of itself for a while, then replace it. But the symmetry and simplicity at the conceptual level is nice, and the ability to have code for both parent and child in the same image is neat.

jolmg 4y ago
It's called trolling. They're using the word "horrible" to bait a response on something that can be easily argued on.
- matheusmoreira 4y ago
  It's called having an opinion and expressing it. You can accept my opinion, ask me to elaborate or convince me it's wrong. What you can't do is accuse me of trolling just because you disagree.
  - jolmg 4y ago
    No, I thought you were being hyperbolic, but after you've explained your problems with signaling, I agree with it. Kind of depressed at the state of that, now...
    - matheusmoreira 4y ago
      You and me both. I've wasted way too many neurons trying to understand this legacy brain damage. Hyperbole doesn't quite do it justice, it's a design that deserves an epic rant like mpv's locale commit: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
kelnos 4y ago
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.
- somat 4y ago
  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 4y ago
    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..
- jolmg 4y ago
  > 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.
mananaysiempre 4y ago
> Forking processes seems like a rather elegant concept, to me. Forking is good because it saves you a rich process manipulation API, and because generally speaking doing things to an execution environment always ends up more clunky than doing things in one. (Cleaning up after doing them is another matter.) Forking is bad[1] because it (essentially if not literally) forces memory overcommit on you, at which point resource accounting becomes hopeless. [1] https://lwn.net/Articles/785430/ https://lwn.net/Articles/785430/
matheusmoreira 4y ago
> Can you please elaborate on why those two ideas are "horrible"? The problems with fork are thoroughly explained by this Microsoft paper: https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... As for asynchronous signals, they are a completely broken concept and implementation. It's not safe to do pretty much anything in a signal handler other than setting a flag and returning. You cannot use any non-reentrant function which eliminates pretty much everything useful, including the vast majority of standard library functions. The system drops events. Signals are essentially a pending delivery flag in the kernel, signaling a process just sets the flag to 1 so there's no difference between doing it once and 10000 times. Was in a system call when your process was signaled? It will be interrupted or cancelled. It returns EINTR and your code needs robust retrying logic to handle such a case. I've seen code that couldn't handle it and crashed. There's race conditions everywhere. Signals can arrive while you're handling other signals, you need to block block them if you don't want that. Every thread has its own signal handling behavior. Signals sent to a process are handled by "any" thread. I remember reading in some standard that using signals in multithreaded programs was undefined behavior. Who even knows what's going to happen? The only borderline sane way to handle signals is with file descriptors: you block traditional signal handling on all threads and set up a signalfd that you can epoll along with everything else on a thread dedicated to the event loop. Even this is pretty bad: https://ldpreload.com/blog/signalfd-is-useless https://ldpreload.com/blog/signalfd-is-useless https://news.ycombinator.com/item?id=9564975 https://news.ycombinator.com/item?id=9564975
- up2isomorphism 4y ago
  So M$ write this to convince people their CreateProcess is better than fork? Not smart. Thinking signal sucks is just because people trying relying on it to do something it is not designed to do. You can not complain a pile of wood is not a table.
- jolmg 4y ago
  You got me. That is quite horrible.
- throwawaylinux 4y ago

by unwind 4y ago

jolmg 4y ago

It's called trolling. They're using the word "horrible" to bait a response on something that can be easily argued on.

matheusmoreira 4y ago
It's called having an opinion and expressing it. You can accept my opinion, ask me to elaborate or convince me it's wrong. What you can't do is accuse me of trolling just because you disagree.
- jolmg 4y ago
  No, I thought you were being hyperbolic, but after you've explained your problems with signaling, I agree with it. Kind of depressed at the state of that, now...
  - matheusmoreira 4y ago
    You and me both. I've wasted way too many neurons trying to understand this legacy brain damage. Hyperbole doesn't quite do it justice, it's a design that deserves an epic rant like mpv's locale commit: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

kelnos 4y ago

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.

somat 4y ago
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 4y ago
  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..
jolmg 4y ago
> 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.

mananaysiempre 4y ago

> Forking processes seems like a rather elegant concept, to me. Forking is good because it saves you a rich process manipulation API, and because generally speaking doing things to an execution environment always ends up more clunky than doing things in one. (Cleaning up after doing them is another matter.) Forking is bad[1] because it (essentially if not literally) forces memory overcommit on you, at which point resource accounting becomes hopeless. [1] https://lwn.net/Articles/785430/ https://lwn.net/Articles/785430/

matheusmoreira 4y ago

> Can you please elaborate on why those two ideas are "horrible"? The problems with fork are thoroughly explained by this Microsoft paper: https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... As for asynchronous signals, they are a completely broken concept and implementation. It's not safe to do pretty much anything in a signal handler other than setting a flag and returning. You cannot use any non-reentrant function which eliminates pretty much everything useful, including the vast majority of standard library functions. The system drops events. Signals are essentially a pending delivery flag in the kernel, signaling a process just sets the flag to 1 so there's no difference between doing it once and 10000 times. Was in a system call when your process was signaled? It will be interrupted or cancelled. It returns EINTR and your code needs robust retrying logic to handle such a case. I've seen code that couldn't handle it and crashed. There's race conditions everywhere. Signals can arrive while you're handling other signals, you need to block block them if you don't want that. Every thread has its own signal handling behavior. Signals sent to a process are handled by "any" thread. I remember reading in some standard that using signals in multithreaded programs was undefined behavior. Who even knows what's going to happen? The only borderline sane way to handle signals is with file descriptors: you block traditional signal handling on all threads and set up a signalfd that you can epoll along with everything else on a thread dedicated to the event loop. Even this is pretty bad: https://ldpreload.com/blog/signalfd-is-useless https://ldpreload.com/blog/signalfd-is-useless https://news.ycombinator.com/item?id=9564975 https://news.ycombinator.com/item?id=9564975

up2isomorphism 4y ago
So M$ write this to convince people their CreateProcess is better than fork? Not smart. Thinking signal sucks is just because people trying relying on it to do something it is not designed to do. You can not complain a pile of wood is not a table.
jolmg 4y ago
You got me. That is quite horrible.
throwawaylinux 4y ago