I think the reason is that when you are debugging a race condition, the added synchronization resulting from logging can make the problem go away as soon as you start investigating it, which can be quite annoying.
BTW, there is a way to do atomic writes (at least on posix systems, I don't know if there is a windows equivalent) without locking: write the string to a temporary buffer in memory (as you do now), and then write it to a file which was opened with O_APPEND with a single system call. Your implementation probably already does this, so all you need to do is make sure O_APPEND is set. cheers, pl On 11 May 2015 at 16:23, Zachary Turner <ztur...@google.com> wrote: > +greg. I'm not sure either tbh, if there's no contention the cost of > acquiring the mutex should be free, and if there is contention then the lock > is required. > > On Mon, May 11, 2015 at 7:29 AM Ed Maste <ema...@freebsd.org> wrote: >> >> On 8 May 2015 at 14:50, Zachary Turner <ztur...@google.com> wrote: >> > Author: zturner >> > Date: Fri May 8 13:50:54 2015 >> > New Revision: 236892 >> > >> > URL: http://llvm.org/viewvc/llvm-project?rev=236892&view=rev >> > Log: >> > Enable thread-safe logging. >> >> Thanks for fixing this up Zach. >> >> This raises a question though, going back to the original introduction >> of logging support -- why is this an option at all, never mind a user >> facing option? It's particularly odd that we default to thread-safe, >> unless any other options are specified. It seems to me we should just >> remove the thread-unsafe path. > > > _______________________________________________ > lldb-commits mailing list > lldb-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
