On 04/07/13 08:05, Dan McGee wrote:
On Wed, Jul 3, 2013 at 4:38 PM, Simon Gomizelj <simongmzlj@gmail.com> wrote:
That said, the loop is possibly a source of bugs for another reason, apparently its possible for the fd to have been closed and reused by the time EINTR fires, causing an unrelated fd to be closed.
As discussed in this thread, many POSIX implementations, including Linux, will release the file descriptor immediately, and so if close() fails with EINTR, it is possible that the file descriptor has already been reclaimed and in use by some other component. Retrying the close call, therefore, might close some other component's descriptor.
- https://sites.google.com/site/michaelsafyan/software-engineering/checkforein... - http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html
Given that we are single-threaded, I don't see how this is possible.
This is not possible now... but there is code floating around to set this up and I would like to use it for at least integrity checking. Also, this appears to be the right thing to do whether we are single- or multi-threaded. We should fix the issue whether or not we can expose it. Allan