Date: Sun, 24 Jul 2011 18:29:26 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: close(2) failure cases (was: some fixes to musl) On Sun, Jul 24, 2011 at 09:49:03PM +0400, Vasiliy Kulikov wrote: > Rich, > > On Sun, Jul 24, 2011 at 08:24 -0400, Rich Felker wrote: > > > Even if close() fails, the fd is freed. So fd leakage is impossible. > > > > Is this true even in the case of EINTR? > > For all types of fd the fd is deleted from fd table, then > FS-specific function is called. Any error would be returned to the > program, but fd would be already deregistered. Good to know. I may need to investigate and verify that this behaves as expected in conjunction with thread cancellation while blocked at close(), and if not, work on a work-around... Do you know any reliable way to setup the kernel to block/sleep for a measurable length of time on close() so that I could test this? > I agree with POSIX in part that close() should somehow signal about > failed IO (e.g. no free disk space) and error return code is good > enough. However, I feel it was wrong to leave undefined behaviour of fd in > case of error. If the file is so important that the error must be > handled by the program, it really should do *sync() and react on its > error. IMO close() should unconditionally close fd. (The same for > fclose(3), etc.) Note that the way POSIX leaves the state of the fd indeterminate if close fails makes it impossible to write robust portable multi-threaded programs that use files in any non-trivial way. You can't retry closing a file descriptor you already passed to close, because it might get assigned to a new file opened in another thread, in which case you would close the other thread's newly-opened file. I consider this a major flaw in the standard (one of the many oversights of not considering the interaction of certain behaviors with threads) and hope to raise the issue as a defect report and push for the next version of the standard to define the behavior that the fd always be freed. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.