close() can be interrupted with undefined behavior
Lassi Kortela
(21 Jul 2019 11:44 UTC)
|
Re: close() can be interrupted with undefined behavior
Duy Nguyen
(21 Jul 2019 11:59 UTC)
|
Re: close() can be interrupted with undefined behavior
Lassi Kortela
(21 Jul 2019 12:11 UTC)
|
Re: close() can be interrupted with undefined behavior
Duy Nguyen
(23 Jul 2019 10:17 UTC)
|
Re: close() can be interrupted with undefined behavior hga@xxxxxx (21 Jul 2019 12:42 UTC)
|
Re: close() can be interrupted with undefined behavior hga@xxxxxx 21 Jul 2019 12:42 UTC
> From: Duy Nguyen <xxxxxx@gmail.com> > Date: Sunday, July 21, 2019 6:59 AM > On Sun, Jul 21, 2019 at 6:45 PM Lassi Kortela <xxxxxx@lassi.io> wrote: >> "POSIX close(2) is broken", Colin Percival and Taylor Campbell, 2011. >> <http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html> >> Apparently POSIX close() can cause EINTR and leave the file descriptor >> in an unknown state :D > At least on Linux EINTR on close() seems impossible [1]. I don't know > what other POSIX-y OSes do though. OpenBSD, which aims for correctness as part of its security focus, allows for EINTR: https://man.openbsd.org/close Ugh. My Bionic Beaver close(2) man page says it can happen if close is interrupted by a signal. Let's hear it for New Jersey (https://en.wikipedia.org/wiki/Worse_is_better)! EIO and the more specific ENOSPC and EDQUOT in Linux are inevitable for write back caching filesystems, especially ones over a network, and I don't see any sort of "super-close" as making much sense, real and unrecoverable at this level errors occurred earlier when you wrote too much data to a filesystem, the network connection gets dropped between the write and close, etc. That does suggest adding a "POSIX Gotchas" section to the SRFI, for this sort of behavior which we don't expect to be fixed in any future versions of UNIX like operating systems. Although that could be limited to pointing the user to the works of W. Richard Stevens and the like. And given the complete mess that Linux and today's hardware provide to users, you can't assume anything about any sort of close or synchronized write operations in terms of persistence. Thus my concept of one or more "Persistence Manager" SRFIs some day, that take that into account and focus on sane recovery after a hardware or operating system oops. I'll focus first on log style writing, which can be a very useful building block for all sorts of levels. - Harold