Document (in?)ability to exit a program

[zslayton]

Rust doesn't seem to provide a means of cleanly exiting the process apart from programmatically ending all of one's tasks and then allowing the main task to run to completion. Some folks are turning to std::libc::exit as an alternative, which @chris-morgan has pointed out might have undesirable consequences.

This feature is common in many other languages:

• exit() in C
• System.exit() in Java
• sys.exit() in Python
• os.Exit() in Go

It may be worthwhile to document why it is impractical for Rust to provide it as well.

[ben0x539]

I think Chris Morgan is overstating how problematic libc::exit is and I think it ought to be exposed in std::os or somewhere, not just as a C binding. I don't think we usually consider resource leaks a safety issue and exiting early without doing further cleanup seems fairly common in C/C++ where it's not really any cleaner than it would be in Rust.

[ben0x539]

(I'd bet the lack of exit in the standard library dates back to when people thought Rust was going to be a lot more Erlang-like than it actually ended up being.)

[chris-morgan]

@ben0x539 I don’t think I overstated it—the fact that buffered writers will not flush and so data loss may ensue is sufficient for me to consider the libc exit approach catastrophic in the general case. Rust values correctness; libc::exit simply makes a mess of that. That function needs massive warnings on it about what it can do; merely marking it unsafe is necessary but not sufficient. (It doesn’t even have docs!)

[ben0x539]

Rust values safety, I don't think it is particularly preoccupied with correctness.

None of the libc bindings really have docs, but then I suppose the manual pages that came with my linux installation don't really spell out that exit does not flush non-libc buffers either.

[reem]

I agree with @chris-morgan - libc::exit at least needs to be documented explaining that it can cause significant correctness problems if not used correctly.

@ben0x539 I disagree strongly that Rust doesn't care about correctness - much of the emphasis on safety is to make it easier to write correct programs.

[quantheory]

A few thoughts:

• I don't have a very clear, strong motivating example for this in my head yet.

  • "Catastrophic" errors (see RFC 236) should generally use panic!.
  • "Obstructions" should be propagated upward toward code that can decide what to do about them.
  • "Normal" exiting, like in the Stack Overflow question, usually only happens in a few places in a program. Because normal termination doesn't happen that often, it shouldn't usually be that difficult to pass information up to main by returning bool or Option from any function that wants to signal a need to exit.

  So panic! is the correct call when exiting due to errors, and I have trouble thinking of a situation where it would be particularly hard or tedious for a program to return up to main if it completes with no errors. (I'm not saying that there's not such a situation, but I can't picture one right now.)

• Calling libc::exit is potentially more dangerous in Rust than in C/C++.

  • C at least flushes/closes the standard library's streams and runs atexit functions.
  • In C++, you also have destructors run on thread-local and static objects.

  While not as safe as stack unwinding, there is of course a better chance of successful cleanup in both cases compared to just immediately terminating the process. I don't know that any of the above is done by Rust right now. If not, then calling libc::exit in Rust is more like calling std::terminate in C++.

[zslayton]

So panic! is the correct call when exiting due to errors ....

A minor gripe I have with panic! as the standard means of exiting in the event of an error is that I don't have control over the output that it produces. It will always take the form:

task '

' panicked at ''

I'd like a way to exit without the boilerplate.

[thestinger]

@chris-morgan: It hardly needs massive warnings. It's not any different than going out-of-stack (abort), out-of-memory (abort or OOM killer), a power outage and so on. The code already needs to be robust against failures like this by making use of transactions. Leaking resources before exit is not a safety issue and is not wrong either.

[chris-morgan]

@thestinger: I think there’s still a significant difference, one of intent; those are known problems that nothing much can be done about and which are truly exceptional circumstances, though I quite agree with you that making software robust against spontaneous failure is an important thing. But in this case we’re talking about a snippet of code deliberately invoked that, based on people’s experiences in other languages, may not do what they expect. It is the factor of expectation that clinches this one, in my opinion.

[quantheory]

A minor gripe I have with panic! as the standard means of exiting in the event of an error is that I don't have control over the output that it produces.

True. Maybe there should be a more advanced macro that's even more general than the formatted form of panic, e.g. passing the the file/line information to a user-defined method and letting it figure out the final message/logging. (Of course you can just call std::rt::begin_unwind yourself, or do so in your own macro, but I don't know when if ever begin_unwind will be stable.)

At the same time, my understanding is that panic! is mostly for situations where the error is most likely due to a bug in the program (or likely-unrecoverable cases like out-of-memory errors), which ideally shouldn't be seen much by users. Errors having to do with I/O, communication, permissions, etc., which are more likely to be user-visible, and which the user is more likely to be able to actually do something about, are supposed to be propagated upward by returning Result, not by exiting/aborting/panicking from wherever you encounter them.

(Admittedly, I'm not sure how well that will end up. It requires a lot less language complexity and opportunity for mistakes than if an exception mechanism was added, but I imagine that a lot of codes will have a ton of try! and Result all over them.)

It hardly needs massive warnings.

Eh, I guess "massive" is a matter of opinion. If it was moved/reexported outside of libc, it would certainly need some warning just to note that, unlike other ways you can exit, it does no cleanup. But it's a less important point if it isn't moved out of libc, and I still don't see why it should be.

If you really must abort now, you should probably use panic! (or some other thing like unwind_and_die! could be created if panic! turns out not to be general enough). If you really, deliberately want to exit without doing so, you can always go find the function in libc. But I don't know why we would advertise this function, since it isn't really what people will generally want, and it potentially violates invariants that (except in cases like your power outage) could otherwise be enforced by the destructors.

those are known problems that nothing much can be done about [... b]ut in this case we’re talking about a snippet of code deliberately invoked

This.

[thestinger]

extern crate test;

fn abort() -> ! {
    test::black_box(&());
    abort()
}

fn main() {
    abort();
}

[thestinger]

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        panic!()
    }
}

fn abort() -> ! {
    let _x = Foo;
    panic!()
}

fn main() {
    abort();
}

[thestinger]

extern crate test;

fn abort() -> ! {
    let xs = Vec::from_elem(std::uint::MAX, 1u8);
    test::black_box(&xs);
    loop {}
}

fn main() {
    abort();
}

[thestinger]

@chris-morgan: Rust is going to be switching to detached threads for spawn. The program will exit as soon as you fall off main and you'll need to explicitly synchronize if you want it to block until other tasks are done their work. The alternative is the overhead of extra synchronization and a mandatory hosted runtime incompatible with running code on threads managed by the C standard library. Are you against removing the runtime?

[thestinger]

It's also easy to exit by raising a signal. There was some discussion about this, and the reference manual now states that raising / sending signals is not unsafe based on the consensus.