std.process.cleanExit so we can not clean up our cake and eat it too

[andrewrk]

/// Indicate that we are now terminating with a successful exit code.
/// In debug builds, this is a no-op, so that the calling code's
/// cleanup mechanisms are tested and so that external tools that
/// check for resource leaks can be accurate. In release builds, this
/// calls exit(0), and does not return.
pub fn cleanExit() void {
    if (std.builtin.build_mode == .Debug) {
        return;
    } else {
        std.process.exit(0);
    }
}

Calling code would look something like this:

var foo = allocateResource();
defer cleanupResource(foo);

if (condition) {
    return std.process.cleanExit();
}

[joachimschmidt557]

I think this has a potential to be a footgun if this function is not called from main():

const std = @import("std");

fn foo() void {
    return std.process.cleanExit();
}

pub fn main() !void {
    foo();
    std.debug.print("helo\n", .{});
}

On debug builds, this prints helo and on release builds, it prints nothing. This difference in behaviour may be very risky.

[ikskuh]

I don't think this is a good idea. Afaik if you don't clean up your sockets nicely, it will have effects when restarting the same program (afaik: if your process crashes, you cannot rebind the same socket for some minutes unless you use SO_REUSEADDR and then it's only possible with the same program). I don't think this is desirable as a default behaviour for release builds.

Also cleaning up resources with defer might do some more complex logic like notifying a server of a clean shutdown

[BarabasGitHub]

Also cleaning up resources with defer might do some more complex logic like notifying a server of a clean shutdown

I was also thinking about this, but should that really be in a defer? There's no way to handle errors in defer statements, so it might already never send the shutdown message.

I do agree that it looks fishy. I'd rather call it uncleanExit or hardExit or something which indicates that it's a hard shutdown without any cleanup. And indeed I'm not sure cleaning up in debug is a good idea.

[joachimschmidt557]

Alternative solutions to std.process.cleanExit:

1. Change the definition and implementation of a defer statement to run code right before control flow leaves a scope.
2. Discourage the use of std.process.exit and instead use return values of main

For 1, the new definition would mean that calling a noreturn function such as std.process.exit would qualify as leaving the scope, whereupon the defer statements would be run.

In 2, this can be done:

pub fn main() !u8 {
    // instead of: std.process.exit(1);
    return 1;
}

[Rocknest]

@joachimschmidt557 see #2198 (comment) for case (1).

[thejoshwolfe]

i ran into a use case for this here: https://github.com/andrewrk/groovebasin/blob/b27b4e02baa13e88d601e8008fd9d59b55d7ff22/tools/paste-js.zig#L59-L60

It does me no good to meticulously deallocate all my memory when the process is going to exit anyway. Is there a reason to close my open file descriptors before my process exits? Pretty sure the OS will do that for me. (I don't have any unflushed output buffers to worry about.)

I'm not an expert on SO_REUSEADDR, but I don't see any evidence in the documentation that it's affected by the application closing the socket before exiting. Someone please correct me if I'm wrong.

[thejoshwolfe]

The name "cleanExit" is one problem with this proposal. At first glance, that sounds like it's going to run a bunch of atexit-like deinitialization code. If i wanted to shutdown my process quickly and abruptly, I would not reach for something named "cleanExit".

Another problem is the intended way to use this function is unintuitive. You're supposed to return it from main, but the function signature doesn't indicate that. In order to make this function signature not a footgun, we could change the way main() declarations work to have a special return type fn main() !std.process.ExitStats { which is returned by fn cleanExit() ExitStatus {. That gives the programmer the intuition to connect the dots. However, I'm not sure we want to disrupt main() like that just for this feature.

[andrewrk]

I think the intended usage pattern of this is too subtle for it to go into std. It's 4 lines, no problem for application developers to provide. Thanks all