labath added a comment. In https://reviews.llvm.org/D25783#574684, @zturner wrote:
> There are many other problems with this code if we want to deal with > atomicity. For example, the whole point of this patch was to handle short > reads and writes. Well, if you have a short read or a write, then reading > and writing a subsequent chunk is not atomic. I am willing abandon the atomicity if someone tries to write more than 2GB of data - I think he has bigger problems than that. > That being said, I don't think it's hugely important here. The worst that > will happen is two log messages will be printed out of order. I don't think > anything will be corrupt or interwoven. For example, if two threads come in > at the same time and both compute the same file size, they will both attempt > to write at the same offset. One will win, the other will insert right > before the message. So it's possible the two could wind up reversed, but > that's about it. I am not sure what you mean by "insert right before the message". The second thread will just overwrite the thing that the first one wrote (plus you'll end up with a dangling fragment at the end if the second message was shorter. > Only way to deal with multi-threading correctly is to put all this in a mutex. Actually, a mutex cannot handle this case if you have the multiple file descriptors (possibly in multiple processes) referring to the same file. That is the reason why append mode exists - to let the kernel do the arbitration. https://reviews.llvm.org/D25783 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
