Ironically it's actually the opposite. Linux has signals, and with the exception of SIGKILL and I think SIGABRT they can all be handled gracefully. Windows on the other hand doesn't have signals, it can only TerminateProcess() which is forceful. The illusion of graceful termination on windows is done by sending a Window close message to all of the windows belonging to a given process, however in the event the process has no windows, only forceful termination is available due to the lack of a real mechanism to gracefully terminate processes. That's why the taskkill command tells you a process requires forceful termination when you run it against something headless.

[–] Feyd@programming.dev 60 points 18 hours ago* (last edited 18 hours ago) (1 children)

You're right about Linux but you're wrong about windows. It is sent to the event loop in windows https://learn.microsoft.com/en-us/windows/win32/winmsg/window-notifications. It's been a long time since it was my job, but you actually had to pass a certification that your application exited gracefully in response to these messages as part of the partner program back in the day.

[–] Scoopta@programming.dev 1 points 2 hours ago

You clearly didn't read my message...I said a "window close message." I.e...WM_CLOSE. that is not a process signal, it's a window management signal. Hence taskkill not working without /f on headless processes

[–] mkwt@lemmy.world 86 points 19 hours ago (1 children)

Windows does, in fact, have signals. They're just not all the same as Unix signals, and the behavior is different. Here's a write-up.

You're correct there is no "please terminate but you don't have to" signal in Windows. Windowless processes sometimes make up their own nonstandard events to implement the functionality. As you mentioned, windowed processes have WM_CLOSE.

Memory access violations (akin to SIGSEGV), and other system exceptions can be handled through Structured Exception Handling.

[–] Scoopta@programming.dev 11 points 19 hours ago (1 children)

TIL about the console signaling stuff, good to know. I am aware of SEH but that seemed a little too in the weeds for this discussion since that's as you say akin to SIGSEGV

[–] marcos@lemmy.world 13 points 18 hours ago

The NT kernel was all built to emulate object orientation (read Smalltalk, not C++) style message passing. That's because it was the 90s, and it's the new technology kernel.

So yeah, expect everything to have more flexibility sending data around, and no standardization at all so you can't have any generic functionality.

[–] RickyRigatoni@retrolemmy.com 8 points 17 hours ago

sig bart

[–] 30p87@feddit.org 10 points 20 hours ago

That's fucked up

[–] Rhaedas@fedia.io 8 points 20 hours ago (1 children)

It also means the OS is in total control of the things it's running. This goes for running programs, shutting down, and crashing. The only crashes I have on my Linux are when I use up memory, and I'm still convinced that even though everything looks seized up, if I left it for hours or days it would probably end up resolving itself. I've had some cases where the OS saw the program wasn't going in a good direction fast enough and killed it.

[–] SaharaMaleikuhm@feddit.org 2 points 14 hours ago

Most linux systems have two OOM killers, one in the kernel that will execute as a last resort when your system is already frozen up, and one in systemd that should run earlier to prevent your system from freezing up. That one works sometimes, I think it does an okay job actually.

[–] xan1242@lemmy.dbzer0.com 1 points 19 hours ago

Plus, if something seemingly can't be terminated with that, 99% of the time it's a kernel level lockup (e.g. disk IO). At which point you only have 2 options: kill it via a kernel debugger or (the more likely scenario) perform a reboot.