Yeah, of course they shouldn’t, but they do. Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down. DDoS for example. It’s not a solved problem.
Wax idealistic all you want, but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one. “No userland APIs, private or otherwise, should be able to crash your app!!!” Is the argument I would be responding to right now.
> Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down.
> > userspace app could trigger <...> and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope
If userspace triggers what is an effectively a DoS attack and you cannot login to root terminal and get things sorted out that's a system not designed for adversarial userspace.
> but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one
A more general context we are discussing here is resource exhaustion. There are myriads of scenarios where userspace can cause some form of resource exhaustion. My argument is that a 1) well designed 2) general use system should implement resource management in a way (e.g. priority queues) that userspace-inflicted resource exhaustion does not affect performance envelope of the system itself. Otherwise the system is open to unprivileged DoS attacks with only recourse being power cycling.
If your userspace app overcommits memory to some monstrous degree, what should the system do?
1. Enter a swap feedback, crippling the system down to unusability.
2. OOM-kill a process based on some heuristics.
3. freeze userspace, leaving privileged space functional.
I think you’re losing me. This is all completely tangential to the current discussion, bordering on non-sequitur. I don’t know why you chose to latch onto my loose quip of “bring the whole system down”, because that’s not what is happening here. I thought you knew that.
The OS got a little slower, that’s it. It was never in some unrecoverable state. One could soft close the offending processes at anytime and regain the lost perf. I’m willing to bet you could hide or minimize the window to mitigate the issue, because the bug is very specific to the layout and render run loop, which auto-pauses on lost visibility by default.
That said, I haven’t even noticed the slowdown on my work machine, but I only use Teams. it’s always been dog shit slow, just par for the course.
Wax idealistic all you want, but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one. “No userland APIs, private or otherwise, should be able to crash your app!!!” Is the argument I would be responding to right now.