From owner-freebsd-questions@freebsd.org Wed Jun 16 00:34:15 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 55FB06577A4 for ; Wed, 16 Jun 2021 00:34:15 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4R5L0yRKz3vcT for ; Wed, 16 Jun 2021 00:34:13 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-96-230-243-2.bstnma.fios.verizon.net [96.230.243.2]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4G4R5K3wqcz44sP for ; Tue, 15 Jun 2021 20:34:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1623803653; bh=FdV1QE76EMwhMoSLIUUkHzRyMtm0+ILB1jvqBvrn/e0=; h=Subject:To:References:From:Date:In-Reply-To; b=n3AelY0bBI/zZykj9qJ2EsXQYNsJ9GzNyVDBDKzobGosXi2MdrsIDDxHlcnpKHwbp fqlnUVtaribuVhvvkYubFRshSyrJJPQ08eMJoiLH1aUv0TGWiivQFpT5K/UNoA9VKv 9AZSrkBf5oNY9BlI25oWDOMGZeS5Dl7ngduNkgwo= Subject: Re: Is a successful call to write(2) atomic? To: freebsd-questions@freebsd.org References: <22440.1623740785@segfault.tristatelogic.com> <44e15917-0c92-08f2-462e-a1b3705f9afb@panix.com> <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org> From: Kurt Hackenberg Message-ID: <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com> Date: Tue, 15 Jun 2021 20:34:10 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210615234328.b2de12c70efe6efaee17ec1e@sohara.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G4R5L0yRKz3vcT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=n3AelY0b; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-4.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; R_SPF_ALLOW(-0.20)[+ip4:166.84.0.0/16:c]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_IN_DNSWL_MED(-0.20)[166.84.1.89:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.230.243.2:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[panix.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.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: Wed, 16 Jun 2021 00:34:15 -0000 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.