-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document (in?)ability to exit a program #19245
Comments
I think Chris Morgan is overstating how problematic |
(I'd bet the lack of |
@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; |
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 |
I agree with @chris-morgan - @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. |
A few thoughts:
|
A minor gripe I have with
I'd like a way to exit without the boilerplate. |
@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. |
@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. |
True. Maybe there should be a more advanced macro that's even more general than the formatted form of At the same time, my understanding is that (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
Eh, I guess "massive" is a matter of opinion. If it was moved/reexported outside of If you really must abort now, you should probably use
This. |
extern crate test;
fn abort() -> ! {
test::black_box(&());
abort()
}
fn main() {
abort();
} |
struct Foo;
impl Drop for Foo {
fn drop(&mut self) {
panic!()
}
}
fn abort() -> ! {
let _x = Foo;
panic!()
}
fn main() {
abort();
} |
extern crate test;
fn abort() -> ! {
let xs = Vec::from_elem(std::uint::MAX, 1u8);
test::black_box(&xs);
loop {}
}
fn main() {
abort();
} |
@chris-morgan: Rust is going to be switching to detached threads for |
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 |
I see the point about safety; I would say that these cases are not But I'm worried that we're starting to drift off-topic. I think that the questions to be resolved are:
|
|
Oops, missed this reply.
OK. There are three ways I can think of to deal with that:
It's not clear to me that either of these justifies a separate macro rather than changing/enhancing |
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 CSystem.exit()
in Javasys.exit()
in Pythonos.Exit()
in GoIt may be worthwhile to document why it is impractical for Rust to provide it as well.
The text was updated successfully, but these errors were encountered: