Add a BufferedLogHandler as requested by Greg in D127986.
Details
Diff Detail
Event Timeline
I feel I should note that the llvm streams already have a buffered mode, and given the way things are implemented now (our log class writes the entire log message in one call, and the raw_ostream flushing the entire buffer whenever a message does not fit), I don't think this class has any advantages over using stream buffering (that's a very long-winded way of saying you're not going to get partial messages in either of the solutions). The only two differences I see are:
- one of them specifies the size, the other specifies the number of messages
- different behavior in case of races (in non-thread-safe mode). I'll write more on that elsewhere.
As I said in the other patch, I (personally) don't really care all that much about buffering except for the circular buffer. I've implemented an alterantive, stream based buffering approach in https://reviews.llvm.org/D127986. I'll put up a separate patch for the circular buffer.
This is an interesting take that makes more sense than specifying a size in bytes and a "m_circular" since that kind of thing could cut the first message. Saving entire messages as they are logged might make more sense for our circular log messages as we would ensure we have full message lines, though it does come with a "copy each message" cost
lldb/source/Utility/Log.cpp | ||
---|---|---|
361 | maybe assert size > 0 here to make sure we don't crash in Emit() or set m_size to 1 if size is zero? | |
366 | If we are going to buffer, I worry about the performance with saving an array or strings that must be copied each time. Though I do like that we are saving messages as entire buffers. If we go the circular buffer route we can either have one fixed size buffer that we copy into and then try the keep the current insert index, or copy the strings like you are already doing. |
maybe assert size > 0 here to make sure we don't crash in Emit() or set m_size to 1 if size is zero?