Date: Tue, 15 Jun 2021 20:34:10 -0400 From: Kurt Hackenberg <kh@panix.com> To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? Message-ID: <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com> In-Reply-To: <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org> References: <22440.1623740785@segfault.tristatelogic.com> <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021/06/15 18:43, Steve O'Hara-Smith wrote: >> No, write(2) is not guaranteed atomic, and that's not obvious. Probably >> a lot of people have learned that the hard way. > > Strangely (after posting a confident no it isn't guaranteed) I > noticed this in write(2) which implies that it is guaranteed to write a > contiguous block (at least for seekable objects): > > -------------- > On objects capable of seeking, the write() starts at a position given > by the pointer associated with fd, see lseek(2). Upon return from write(), > the pointer is incremented by the number of bytes which were written. That's talking about the pointer associated with the file descriptor. The system call fork() gives the child process *copies* of file descriptors. Not clear whether that pointer is also copied. That man page doesn't discuss concurrent writes; I wouldn't swear to the exact meaning of that quote. I think Ronald has effectively written test code, and got garbled output.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?76ccd29b-d54b-803f-4b02-a565bb649eca>