<div dir="ltr"><div class="gmail_extra">> I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write().</div><div class="gmail_extra"><br></div><div class="gmail_extra">Do you mean raw_fd_ostream somehow overrides the operator<< the code for which I extracted?</div><div class="gmail_extra">I cannot see if that is so. And I really saw it didn't albeit in a very old master.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> I agree. Acquiring a lock on each write to a buffered raw_ostream is too expensive. You can always explicitly use std::mutex if you have shared raw_ostreams.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course you can do it in your code. But there's a lot of "dbgs() <<" in the backends.</div><div class="gmail_extra">And e.g. if you want to have multithread invocation of a debug version of the lib, but without changing the backend... you might get the race condition.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That's why I'm asking if there's a good way to avoid a problem like that.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 9:12 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
> On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> This code from raw_ostream.h is really racy:<br>
><br>
>   raw_ostream &operator<<(StringRef Str) {<br>
>     // Inline fast path, particularly for strings with a known length.<br>
>     size_t Size = Str.size();<br>
><br>
>     // Make sure we can use the fast path.<br>
>     if (Size > (size_t)(OutBufEnd - OutBufCur))<br>
>       return write(Str.data(), Size);<br>
><br>
>     if (Size) {<br>
>       memcpy(OutBufCur, Str.data(), Size);<br>
>       OutBufCur += Size;<br>
>     }<br>
>     return *this;<br>
>   }<br>
<br>
</span>I don’t believe "the is racy” is an appropriate qualification, “buffered raw_ostream are not providing a thread-safe API" seems more accurate to me.</blockquote><div><br></div></span><div>I agree. Acquiring a lock on each write to a buffered raw_ostream is too expensive. You can always explicitly use std::mutex if you have shared raw_ostreams.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><span><br>
<br>
> Of course, one might wonder why someone would need to output to a stream from multiple threads at the same time.<br>
><br>
> But imagine someone might get logs to dbgs() or errs() running the backend for a target in multiple threads.<br>
<br>
</span>These are unbuffered, I wouldn’t expect a race in the code you list above. I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write().<br>
<br>
—<br>
Mehdi<br>
<br></span>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>
</blockquote></div><br></div></div>