News for hackers. Stuff that matters.
Re:POSIX close(2) is broken by FooBarWidget on Saturday December 17, 2011 @05:36AM (#3363985)
What about other operating systems like FreeBSD, Solaris and OS X? I have to support many platforms and my code is heavily multithreaded.
Re:POSIX close(2) is broken by saurik on Saturday December 17, 2011 @06:48AM (#3364066)
FreeBSD: It seems pretty clear in FreeBSD that you should not retry the call to close(); sys_close() calls kern_close() which locks the file, frees the file descriptor (!), and /then/ calls closef() (which, if capable of returning EINTR, is already too late).

http://lists.freebsd.org/pipermail/freebsd-threads/2010-Augu...

http://fxr.watson.org/fxr/source/kern/kern_descrip.c

Mac OS X: Here you should not retry, but you should also be careful; depending on whether you are UNIX2003 you will get different behavior from the close() function from libSystem, directing you to either the syscall close() or close_nocancel().

If you end up with close(), then the first thing that happens is __pthread_testcancel(1) is called, and if the thread is cancelled it will return EINTR before doing anything else: in this case, you would need to retry.

However, I think close_nocancel(), which calls closef_locked(), might be capable of returning EINTR, which will be held and only returned from close_internal_locked() after _fdrelse() has already removed the descriptor.

So, if it is the case that EINTR is capable of being returned from the closef_locked() call, you would need to /not/ retry, which thereby means that the close() version of this call is impossible to use safely on Mac OS X: if I were you I'd avoid it to use close_nocancel() (explicitly if warranted).

http://opensource.apple.com/source/xnu/xnu-1699.24.8/bsd/ker...

Solaris: Unfortunately, I do not know enough about Solaris to provide any useful commentary. :(

Re:POSIX close(2) is broken by nknight on Saturday December 17, 2011 @07:06AM (#3364092)
Notice how long and complex your discussion of this issue is, and how many different systems you have to investigate in depth to even begin to form a coherent picture.

All we're trying to do is close a file safely. This is core functionality that virtually every application will have to depend on. It would be like free() saying it might be interrupted by a signal, and you have no way of knowing if the memory has actually been deallocated or not. That would be insane.

Re:POSIX close(2) is broken by cperciva on Saturday December 17, 2011 @06:12AM (#3364019)
I believe FreeBSD will never return EINTR for close, but I wouldn't bet my life on it. I've heard rumours that Solaris can return EINTR, but likewise I make no guarantees. I have no idea what OS X does.
Re:POSIX close(2) is broken by tedunangst on Saturday December 17, 2011 @10:35AM (#3364382)
If FreeBSD is like OpenBSD, you may get EINTR on NFS, but the file is still dead.