> For those interested, it is pretty simple code in the kernel: > > fs/open.c close() calls __close_fd > fs/file.c __close_fd(): 1. release fdt entry, 2. calls filp_close() > fs/open.c filp_close(): Calls filp->f_op->flush and this the only operation > that > can be interrupted. > > I do not think that it is a big deal but if you really want to address > correctly in > regards to EINTR, just call fsync(fd) successfully and loop on it if it > returns > EINTR before closing the fd. That way, you pretty much guaranty that close() > will not return EINTR.
A small inaccuracy slipped into what I have written flush != sync Only a handful of fs define the file operation flush: exofs nfs cifs ecryptfs fuse For any other fs, close() cannot return EINTR. For the fs that define the flush operation, it seems to be most of the time identical to sync but there is no guaranty that this is 100% accurate and will stay like that in the future. Here is another suggestion: How about blocking signals while closing file? That sounds like the most portable solution but again, personally, I would not care too much about this unlikely event. Just make sure that you do not call close() more than once as it invalidates the fd even when returning an error, IMO that is what is important. ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
