3 ms·

What about other operating systems like FreeBSD, Solaris and OS X? I have to support many platforms and my code is heavily multithreaded.

cperciva 15y ago
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.
- tedunangst 15y ago
  If FreeBSD is like OpenBSD, you may get EINTR on NFS, but the file is still dead.
saurik 15y ago
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-August/004866.html http://lists.freebsd.org/pipermail/freebsd-threads/2010-Augu... http://fxr.watson.org/fxr/source/kern/kern_descrip.c 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/kern/kern_descrip.c 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. :(
- nknight 15y ago
  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.

cperciva 15y ago

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.

tedunangst 15y ago
If FreeBSD is like OpenBSD, you may get EINTR on NFS, but the file is still dead.

saurik 15y ago

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-August/004866.html http://lists.freebsd.org/pipermail/freebsd-threads/2010-Augu... http://fxr.watson.org/fxr/source/kern/kern_descrip.c 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/kern/kern_descrip.c 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. :(

nknight 15y ago
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.