On 23/11/2010, at 15:43, Brandon Black wrote: > 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.
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 ? -- Jorge. _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
