From owner-freebsd-questions@freebsd.org Tue Jun 15 06:11:10 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0046F640A1C for ; Tue, 15 Jun 2021 06:11:09 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4G3ycX2Sl5z4cTg for ; Tue, 15 Jun 2021 06:11:07 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id DB97E4E657; Mon, 14 Jun 2021 23:11:05 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Is a successful call to write(2) atomic? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22222.1623737465.1@segfault.tristatelogic.com> Date: Mon, 14 Jun 2021 23:11:05 -0700 Message-ID: <22223.1623737465@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4G3ycX2Sl5z4cTg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.62.255.118:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[69.62.255.118:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 06:11:10 -0000 OK, here's a stupid programming question. I believed that I knew the answer to this, but now I'm no longer so sure. Assume that a given program, "example", forks a child process (or perhaps many such) and then each of these processes tries, in a manner that is entirely non-sychronized with any of the others, to write blocks of data using calls to write(2) to file descriptor 1. Assume further that "example" is run from the command line as follows: example > ordinary-disk-file Lastly asume that the return value for all calls to write() is diligently checked to insure that it is never either -1 or a short write count, and that if it ever, is, "example" will exit with a non-zero exit status (and assume also that otherwise it will exit with a zero exit status). Question: Assuming that "example" runs and exits with a zero status (thus indicating that all calls to write() completed successfully and none returned a short write count) then might it ever be the case that some single chunk of data that was successfully written to "ordinary-disk-file" by a single call to write() might be split into two or more parts in the output file, with chunks of data that were written by other processes in the same family possibly being interleaved between parts of that one chunk in the output file? In other words: Is a block of data that is successfully written by a single call to write() itself treated as being effectively atomic and indivisible, i.e. with repsect to the physical output file? I have always assumed so, but looking at the man page for write(2) just now I see that it contains no such guarrantee. And in fact, I have an output file which was written to by multiple processes from a family or procsses, and where some of the output appears to have been garbled in the sense of text lines that I know were written by one process being muddled up with lines that were written from other processes from the same family. Of course, this -might- all just be down to my own crappy programming. That's what 'm tryiong to determine.)