Re: io_close proposal
Roland McGrath <[email protected]>
| Newsgroups | gmane.os.hurd.devel.readers |
|---|---|
| Message-ID | <[email protected]> |
> Roland McGrath <[email protected]> writes: > > > You know, I wonder though about the SA_RESTART question. Because that > > would introduce a timing-dependent possible fd leak in every program that > > handles signals. > > Um, can you restate the question? Perhaps I'm missing something, but > I don't think the previous discussion implied such a leak. Suppose a signal with SA_RESTART set is required to interrupt a close call so that it returns EINTR (e.g. breaking an SO_LINGER wait--but the system permitted to treat even an "instantaneous" close call as interrupted with EINTR) and then it's unspecified whether the fd is still open or not. In that case, any application that might handle a signal while calling close must check for EINTR and repeat the close call, or else it may leak the descriptor in the event of a signal. So, if that interpretation holds then a strictly conforming program that doesn't want to leak must do the loop or block signals around calling close or whatnot. That seems like it would bite so many existing programs that I wonder if that could really be the intent.