On 04/07/13 08:05, Dan McGee wrote: > On Wed, Jul 3, 2013 at 4:38 PM, Simon Gomizelj <[email protected]> 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/checkforeintrwheninvokingclosethinkagain >> - 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
