Post #1665422

2026-01-15 00:41 UTC

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.

Replies (5)

@mkwt@lemmy.world 2026-01-15 01:11

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](https://stackoverflow.com/questions/72258181/ctrl-c-event-vs-ctrl-break-event-vs-terminateprocess-on-windows). 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.

Open ##1665458
@Feyd@programming.dev 2026-01-15 02:31

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.

Open ##1665459
@30p87@feddit.org 2026-01-15 00:53

That's fucked up

Open ##1665460
@RickyRigatoni@retrolemmy.com 2026-01-15 03:34

sig bart

Open ##1665461
@xan1242@lemmy.dbzer0.com 2026-01-15 01:18

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.

Open ##1665462