On Tue, Nov 23, 2010 at 4:55 AM, Jorge Chamorro <[email protected]> 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. _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
