[Lldb-commits] [PATCH] D25783: [Host] handle short reads and writes

[Pavel Labath via lldb-commits]

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