signal::windows::ctrl_close does not work as expected

[sorokya]

Version
v1.39.2

Platform
64-bit (Windows)

Description
Tried writing some code for cross platform graceful shutdown in my project but the windows specific callbacks seem to not work.

I tried this code:

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // snip
    tokio::select! {
        ctrl_c = signal::ctrl_c() => match ctrl_c {
            Ok(()) => {},
            Err(err) => {
                error!("Unable to listen for shutdown signal: {}", err);
            }
        },
        close = close() => match close {
            Ok(()) => {},
            Err(err) => {
                error!("Unable to listen for shutdown signal: {}", err);
            }
        }
    }

    info!("Shutting down server...");
    world.shutdown().await;

    Ok(())
}

#[cfg(windows)]
async fn close() -> Result<(), Box<dyn std::error::Error>> {
    let mut close_stream = signal::windows::ctrl_close()?;
    close_stream.recv().await;
    Ok(())
}

I expected to see this happen:
When I closed the console application my world.shutdown().await function would execute which notifies players of the shutdown and saves the server to the database.

Instead, this happened:
The process terminates before world.shutdown().await can run.

[Darksonn]

Thoughts @ipetkov ?

[dtzxporter]

I validated on windows that if you wish to do any closing work after receiving CTRL_CLOSE, you must do it in the handler before returning. The return value just stops calling handlers that are registered.

BOOL myHook(DWORD event) {
    // Say we handled it.
    std::cout << "handled" << std::endl;
    // If we don't sleep, process is killed immediately regardless of return value.
    // E.g, you must do your work in this callback.
    Sleep(5000);
    return TRUE; // True means stop calling handlers, False calls the next handler.
}

int main()
{
    SetConsoleCtrlHandler(myHook, TRUE);

    while (true) {
         std::cout << "Hello World!\n";
         Sleep(1000);
   }
}

The reason why this differs from ctrl_c is that the ctrl_close, the window is closed before the handlers are called, so the process is about to exit. ctrl_c doesn't close anything, and since we ignore the default handler, it doesn't force close the process there.

[ipetkov]

My understanding is/was that returning TRUE should stop other handlers from running including the default handler which would actually halt the process.

If that's not the case, then our implementation is incorrect

[Darksonn]

Hmm. If this is the case, then I guess we'll need to deprecate ctrl_close with a message saying it doesn't work.