On 9/17/2019 7:37 PM, eadwardus_at_disroot.org wrote:
> Posix says about close(2):
>
> "If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified."
Tell me about it...
The fact that close() can be interrupted, or can fail at all, is
a misdesign; the fact that the state of fildes is unspecified is an
even worse misdesign; and everybody agrees on that.
There is no good solution. close() just should not fail, period.
> What means that the file descriptor can be already closed and return EINTR, making the call try to close it again, while this shouldn't be a real problem in single-threaded programs (although would return a fake EBADF), it creates a real problem in multi-threaded programs as you could close other file descriptors that were open in the mean time. Maybe you could verify with fstat if is safe to close again (by comparing the ino and dev values or by receveing EBADF)
Yeah. That's a really heavy workaround for something that's a
theoretical possibility, but almost never happens (you need to be in
a multithreaded program, in a thread that catches signals, and receive
a signal you're catching without SA_RESTART). And the problem will be
addressed in the next version of POSIX.
I'd rather say: just don't use fd_close() if you're multithreading.
I should probably add a note in the documentation about this. Thanks
for reminding me. :)
--
Laurent
Received on Tue Sep 17 2019 - 17:50:52 UTC