| |||||||||||||
When the programmer is forced to handle return codesWhen the programmer is forced to handle return codesPosted Dec 5, 2009 7:18 UTC (Sat) by cras (guest, #7000)In reply to: When the programmer is forced to handle return codes by nix Parent article: On the importance of return codes
Sounds reasonable, yes. But do you think there's a single program that actually is doing the looping,
or even wants to change their code to do this? I've never heard of this being a problem in my code. And actually I think it's probably better not to do the looping anyway. If you get a signal, it means someone wants the process to be killed anyway, so might as well get on with it.
(Log in to post comments)
When the programmer is forced to handle return codes Posted Dec 5, 2009 8:00 UTC (Sat) by quotemstr (subscriber, #45331) [Link] If you get a signal, it means someone wants the process to be killed anyway, so might as well get on with it.There are many signals, only some of which are meant to kill processes. Consider job control. It's also perfectly legitimate (if a little antiquated) to use signals for reporting and miscellaneous functions. You don't want to leak a file descriptor upon receiving a nonfatal signal.
When the programmer is forced to handle return codes Posted Dec 5, 2009 21:35 UTC (Sat) by nix (subscriber, #2304) [Link]
I do it in my code because it *has* caused me a problem (notably
getting -EINTR on write()/close() on NFS-served volumes, and getting -ENOSPC on close()).
(Obviously you actually have helpers that do it. You don't repeat the code
When the programmer is forced to handle return codes Posted Dec 5, 2009 22:47 UTC (Sat) by cras (guest, #7000) [Link]
So I guess you know what happens in Linux when close() fails with EINTR (with NFS)? It won't close
the fd and it should be retried?
I've gotten rid of alarm()s in (most of) my code and there are no child processes, so I'd think close()s
When the programmer is forced to handle return codes Posted Dec 6, 2009 0:05 UTC (Sun) by nix (subscriber, #2304) [Link] So I guess you know what happens in Linux when close() fails with EINTR (with NFS)? It won't close the fd and it should be retried?The EINTR happens if a signal arrives while pending writes are being flushed. At this point, the FD is not yet closed. (But if it were, you could retry it anyway, and you'd get EBADF and would know that it had been closed last time around.) Since you have to loop for write()/read() anyway, looping for close() as well is hardly a killer. (And, yes, I would rather that -EINTR would die die die as fast as possible, but unfortunately it is not dead so we have to deal with it.)
When the programmer is forced to handle return codes Posted Dec 6, 2009 0:29 UTC (Sun) by cras (guest, #7000) [Link]
That also makes me wonder about my fsync/fdatasync calls. I suppose they can also fail with EINTR.
Anyway, as I mentioned above, all signals causing those to my program nowdays should be external so I don't think I will be doing anything about this problem. (Handling is the same for EINTR as for EDQUOT/ESPACE.) Interesting to realize it could be a problem, of course.
When the programmer is forced to handle return codes Posted Dec 6, 2009 11:17 UTC (Sun) by nix (subscriber, #2304) [Link]
POSIX documents that fsync() can return EINTR but does not document it for
fdatasync(). This seems likely to be an oversight to me.
|
|||||||||||||