Closed eezstreet closed 6 years ago
Test further upstream.
What did you do to verify its "crashing inappropriately" ?
All I did was close it via Ctrl+C and via X button and it crashed in both cases without further modifications.
OpenJK behaviour deviates from ioq3. ioq3 uses the signal() functions on all platforms, whereas OpenJK uses signal() for unix but SetConsoleCtrlHandler for Windows.
signal() on Linux interrupts applications by hijacking the "root" thread (and I believe other threads can keep running?)
Windows control handlers spawn a new thread each time, so this is problematic when there's no synchronization in place. signal() interrupts processes on Windows like it does on Unix, except if the signal is a Ctrl+C... (or is there some distinction here between GUI Win32 apps and console apps?)
Hopefully just using signal() everywhere like ioq3 does would work? Can imagine there still being synchronization issues though.
ioquake3 still uses SetConsoleCtrlHandler, wtf you smokin.
https://github.com/ioquake/ioq3/blob/master/code/sys/con_win32.c#L294
The only difference is we never setup the select few common shared signals. Doing so makes it semi-gracefully exit on seg faults though. No notice etc.
Windows does this extra thread thing regardless of setting that from what I have read before.
Th
This was fixed wasnt it?
Not really but it's not really an issue either.
Doesn't seem to happen anymore for me I think
I'll close this then if we don't think it's a problem anymore
It's not supposed to be a graceful kill, but it crashes while shutting down.
The problem seems to be happening because the signal handler for Windows runs on a separate thread from the main thread, and orders the game to terminate while it's in the middle of a gamecode frame.