Date: Tue, 15 Jun 2021 18:13:19 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-questions@freebsd.org Subject: Re: Is a successful call to write(2) atomic? Message-ID: <26479.1623805999@segfault.tristatelogic.com> In-Reply-To: <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <76ccd29b-d54b-803f-4b02-a565bb649eca@panix.com>, Kurt Hackenberg <kh@panix.com> wrote: >> 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. If i am remembering correctly, this is the exact issue that I got verbally beaten up about on a Posix standards group mailing list some months back, simply because there were two -very- similar bits of terminology which had important *but critically different* semantics associated with them. (I don't even remember what the two terms in question were... something like "file descriptor" and "file description"... or at any rate, some two terms that were approximately that close to one another, lexigraphically speaking, and which were thus VERY easy to confuse with one another.) Anyway, if I am rembering correctly, the outcome of my brief foray onto the Posix list in question was that indeed, a fork() causes the child to receive "a copy of" the file descriptor that is open in the parent, *but* that after that each process is effectively on its own and they *do not* thereafter *share* a single common file descriptor but instead each maintains its own separate copy thereof after the fork() (and perhaps also its own separate file pointer, if i am remembering correctly). Thanks for forcing me to remember all this. Now that I have, I see that this may in fact be the explanation for the garbled output files I've seen. I will have to go back and review that email conversation, but again, my recollection is that I got abused because I had failed to grasp that after a fork, both parent & child have their own independent (and initially identical) *copies* of any open file descriptors, but that after the fork, each (copied) "fd" is a separate and distinct thing... *HOWEVER* there is also some thing which exists at an even lower level and which represents the kernel's direct interface to the (opened) output device or file. I need to do some programming now, but now I think I may now understand the actual problem. If I do, then just sending all the output data to some "master" process and having it be the only one making calls to write() may indeed solve the problem. (If it does, then I'll declare that... in my opinion... write() *does not* have any kind of "atomicity" problem, but rather, allowing a child process to write to any given fd which it inherited (a copy of) via fork(), even as other processes within the same process group do likewise will almost always lead to heartache, misery, and garbled output.) Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26479.1623805999>