<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 12, 2013, at 8:48 PM, Dan Gohman <<a href="mailto:sunfish@google.com">sunfish@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Thu, Sep 12, 2013 at 6:33 PM, Filip Pizlo <<a href="mailto:fpizlo@apple.com">fpizlo@apple.com</a>> wrote:<br><blockquote type="cite"><br>On Sep 12, 2013, at 5:49 PM, Dan Gohman <<a href="mailto:sunfish@google.com">sunfish@google.com</a>> wrote:<br><br>On Thu, Sep 12, 2013 at 5:00 PM, Filip Pizlo <<a href="mailto:fpizlo@apple.com">fpizlo@apple.com</a>> wrote:<br><br>llvm::outs() has a static local that closes stdout in its destructor.<br>Obviously, this *really* has to run atexit, and probably can't run at<br>llvm_shutdown() time. Alternatively, it shouldn't close stdout.<br><br><br>Is the issue just that you want it to flush its output?<br><br><br>The issue is that it needs to detect pending I/O errors.<br><br><br>What would you do with pending I/O errors in an atexit() handler?<br></blockquote><br>The code is out there :-). It calls report_fatal_error.<br></div></blockquote><div><br></div><div>Ah, got it - I thought you meant that it had some recovery. Is it clear that this behavior makes sense for llvm::outs, though? To be clear, I'm not asking about changing raw_ostream's behavior in general, but changing the behavior of llvm:outs in particular. We could get the best of both worlds:</div><div><br></div><div>- raw_ostream clients that aren't llvm:outs retains all of the current behavior and performance.</div><div><br></div><div>- llvm::outs has slightly different behavior, that doesn't require atexit().</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite"><br><br>In that case why not do the equivalent of _setvbuf?<br><br><br>_setvbuf is for libc buffering. raw_ostream's implementation was<br>designed to avoid libc buffering because it wasn't as fast.<br><br><br>I understand that _setvbuf is for libc. But why can't raw_ostream do the<br>equivalent for the purpose of llvm::outs()? Is the concern that a program<br>might use outs() (i.e. outputting to stdout) so heavily that buffering<br>becomes critical?<br></blockquote><br>I don't understand what you're asking here. </div></blockquote><div dir="auto"><br></div><div dir="auto">I'm asking because I don't know, and would like to learn. I find your explanations useful, so that if I try to do more ManagedStatic-like refactorings, I'll know what I'm doing. There's also the possibility that I'm on to something but just haven't described it clearly enough, yet.</div><div dir="auto"><br></div><div dir="auto">It's preferable (and sometimes obligatory) for non-compiler-tool clients of LLVM to not end up with atexit() handlers installed by LLVM. The llvm::outs one appears to be less evil and maybe it's even necessary, but I'm not sure I understand why, yet.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">raw_ostream is a simple<br>utility for simple compiler-like tools. It's useful for these tools to<br>exit with a non-zero exit status if they encounter any output error.<br>raw_ostream's current design achieves this automatically, and by<br>default (though it can be overridden).<br></div></blockquote><div><br></div><div>Right, but is llvm::outs() used in a manner where it makes sense for output errors to result in a hard failure? I.e. is it common for tools to be used in a mode where they output data to fd=1, and is it critical for that use-case to report_fatal_error if the I/O fails (and that error didn't already shoot you down with SIGPIPE or similar)?</div><div><br></div><div>-F</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Dan</div></blockquote></div><br></body></html>