-
Notifications
You must be signed in to change notification settings - Fork 833
[NFC] Use quick_exit to skip global cleanup #8212
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
base: main
Are you sure you want to change the base?
Changes from all commits
a4ccef6
1728cd7
a6dc74d
c6732cb
2a9e76b
4b73e35
8afe5b1
2db41f6
9a4a61f
387ffb9
2cb6910
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -135,3 +135,23 @@ size_t wasm::file_size(std::string filename) { | |
| std::ifstream::ate | std::ifstream::binary); | ||
| return infile.tellg(); | ||
| } | ||
|
|
||
| void wasm::flush_and_quick_exit(int code) { | ||
| // We expect C++ files to be flushed by their destructors already. Flush the | ||
| // standard streams manually. | ||
| std::cout << std::flush; | ||
| std::cerr << std::flush; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You might want to add
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not an expert on this, but from the docs I think that is not needed, if all the C++ ostreams are closed? Closing them (e.g. by their destructor) should flush them, so only the standard output streams need special handling?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure but
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or is there some difference between flushing C++ ostreams and C fflush?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
But I think that C command flushes the file handles themselves, while the C++ command also flushes anything buffered at the C++ level..? That is, C++ has buffering in ostream, iirc - am I wrong?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough, I guess you never know if C++ is doing anything here... but i doubt its doing more buffering on top of what C is doing.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added |
||
|
|
||
| // To be safe, also flush at the C level. | ||
| fflush(NULL); | ||
|
|
||
| #if __has_feature(address_sanitizer) || __has_feature(thread_sanitizer) || \ | ||
| __has_feature(memory_sanitizer) || __has_feature(leak_sanitizer) || \ | ||
| __has_feature(undefined_behavior_sanitizer) | ||
| // Avoid quick_exit when using sanitizers, so that leak checks and other | ||
| // things can run during shutdown normally. | ||
| std::exit(code); | ||
| #else | ||
| std::quick_exit(code); | ||
| #endif | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -289,5 +289,6 @@ int main(int argc, const char* argv[]) { | |
| } | ||
| writer.write(wasm, output); | ||
| } | ||
| return 0; | ||
|
|
||
| flush_and_quick_exit(0); | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -674,4 +674,6 @@ int main(int argc, const char* argv[]) { | |
|
|
||
| // Clean up | ||
| free(copy); | ||
|
|
||
| flush_and_quick_exit(0); | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could use
std::at_quick_exitto register a function to explicitly flush the open descriptors. Can that be done for the output file too, or is that already guaranteed by some other means?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(the advantage of this would be that you could just use
std::quick_exit(0)directly at the currentflush_and_quick_exitcallsites)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the output files should be flushed by their destructors? (this PR ensures those destructors run before exit)
Interesting about
at_quick_exit- that could work, though I don't have a preference myself (doesn't seem like a problem to wrapquick_exit, in fact it might be nice for debugging) - wdyt?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion, it doesn't make that much difference in the end, you either have this wrapper, or a callback. You wouldn't have to worry about plumbing the error code through or not, but you are right that the control is conceptually simpler without the callback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it's simpler without the callback - plumbing through the code, which I just added, is easy enough.