[llvm-commits] [LLVMdev] [PATCH] Allow per-thread re-direction of outs()/errs()

[Chris Lattner]

On Jun 1, 2012, at 7:41 PM, Justin Holewinski wrote:

> >
> > Unfortunately, the use of outs() and (especially) errs() is rampant - a simple grep of the 3.1 source tree shows about 1,500 instances.  One of the first things we had to implement in order to make LLVM usable is something very similar to what Justin has proposed.  Centralizing control of the output in outs()/errs() would seem to be an ideal way to let users of LLVM as a library customize it as they see fit without requiring massive source changes.
> 
> Virtually all of those are in DEBUG statements or in llvm/tools.  Neither are relevant to the discussion.
> 
> In a way, they are.  What if I want a debug trace in a multi-threaded context?  Right now, all threads would just spew to the same stream and the result would be unreadable.  If you allow threads to setup their own outs() and errs() streams (transparently to the rest of LLVM), you can intercept these as you see fit, perhaps dumping each to a separate file.  I acknowledge that you could also enforce single-threaded execution for debug runs, but what if you are in the context of a library with no valid stdout/stderr buffers?
> 

This doesn't make any sense.  There is very little sense in trying to use DEBUG (which gets compiled out of optimized builds) in a multithreaded context.  Polluting the purity of outs() and errs() because of this sort of use case doesn't make any sense to me.

outs() and errs() are useful independent of how LLVM happens to use them.  The extensions that you are proposing doesn't make any sense give nthe design of raw_ostream.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120601/87766969/attachment.html>