write()s and pwrite()s from multiple threads in OSX
jorge at jorgechamorro.com
Wed Nov 24 10:46:27 CET 2010
On 23/11/2010, at 15:43, Brandon Black wrote:
> On Tue, Nov 23, 2010 at 4:55 AM, Jorge Chamorro <jorge at jorgechamorro.com> wrote:
>> We've found, in nodejs, that on Mac OSX, when write()ing to a disk file in a tight loop from >= 2 threads, sometimes some write()s seem to fail to write the data but update the fd's file pointer properly, resulting in strings of zeroes ('holes') of data.length length in the file.
> Another way to fix this without locking (at least on my mac running
> snow leopard) is to set O_APPEND when you open the fd. I'd agree that
> concurrent writes from pthreads in the same process should be atomic
> according to POSIX, but in practice I think this is exactly the sort
> of area where you're going to find some platforms with bugs. Most
> issues come down to file position update issues. O_APPEND fixes this
> in some cases because it uses different logic for updating the file
> position (I think concurrency w/ O_APPEND even works inter-process for
> many systems? not sure). The best way to do concurrent writes is of
> course using pwrite() with specific offsets if you're dealing with
> fixed-size records, but O_APPEND is a reasonable solution for
> logfile-like semantics.
You're right, I know, there's no problem with O_APPEND, nevertheless a fix for write()s to non-O_APPEND fds would be a Good Thing™ for Mac users, don't you think so ?
More information about the libev