-
Notifications
You must be signed in to change notification settings - Fork 855
[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
Changes from 4 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,9 @@ size_t wasm::file_size(std::string filename) { | |
| std::ifstream::ate | std::ifstream::binary); | ||
| return infile.tellg(); | ||
| } | ||
|
|
||
| void wasm::flush_and_quick_exit() { | ||
| 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 |
||
| std::quick_exit(0); | ||
| } | ||
| 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(); | ||
| } | ||
| 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(); | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -993,14 +993,20 @@ int main(int argc, const char* argv[]) { | |
| if (options.debug) { | ||
| std::cerr << "j-printing..." << std::endl; | ||
| } | ||
| Output output(options.extra["output"], Flags::Text); | ||
| if (script && options.extra["asserts"] == "1") { | ||
| AssertionEmitter(*script, output, flags, options).emit(); | ||
| } else { | ||
| emitWasm(*wasm, output, flags, options.passOptions, "asmFunc"); | ||
|
|
||
| // Ensure the destructor of Output runs before quick_exit. | ||
| { | ||
| Output output(options.extra["output"], Flags::Text); | ||
| if (script && options.extra["asserts"] == "1") { | ||
| AssertionEmitter(*script, output, flags, options).emit(); | ||
| } else { | ||
| emitWasm(*wasm, output, flags, options.passOptions, "asmFunc"); | ||
| } | ||
| } | ||
|
|
||
| if (options.debug) { | ||
| std::cerr << "done." << std::endl; | ||
| } | ||
|
|
||
| flush_and_quick_exit(); | ||
|
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. Maybe Otherwise you should call the function
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 was thinking that for errors we don't really care about a quick exit anyhow, so this would only be used for the fast/success path? But I don't feel strongly.
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 I still think its good to be explicit here. I think passing zero is the cleanest way. But you could also call it
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. Added explicit 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.