Is the trace file created by RapidCodeObject::TraceFileSet() buffered? Suppose I wanted to check the contents of the file without closing it, could I expect it to contain everything up to that point in time, or would I have to close it to ensure that the contents of the trace are actually flushed to the file?
Alternately, is there a way to accomplish tracing without going through a file? In the end, what I want is to get/keep the trace in memory and send it to my own logging mechanism.
If you don’t use a TraceFileSet, it should print to the standard output. You are likely to get spammed unless you limit the Trace mask though. We don’t have a way to access the buffer or file short of Closing the TraceFile and then restarting it. Is that an option for you?
I’m attempting to design a multithreaded solution and it’s possible that two different threads would want a trace for overlapping periods of time. If I stop/start to achieve a flush, it complicates things a great deal to get all the trace information (too much is OK, too little is undesirable) to all the consumers. My thought was that if I could read the output without closing the file, there would be no chance of trace messages getting lost in the moment between close and open and it would be a better solution.
In practice, we don’t always get what we want, and this feature is only a troubleshooting tool. I just wanted to design it with sufficient forethought that I don’t kick myself later for having been lazy.
How much time might elapse between adjacent TraceFileClose() and TraceFileSet() calls? Or, how likely am I to miss trace messages (regardless of elapsed time) between those two calls?