| |||||||||||||
When the programmer is forced to handle return codesWhen the programmer is forced to handle return codesPosted Dec 5, 2009 11:40 UTC (Sat) by hppnq (guest, #14462)In reply to: When the programmer is forced to handle return codes by nix Parent article: On the importance of return codes If the file descriptor is actually gone -- which I think is the case also if close() returns with EINTR -- it may have been reused already in a multi-threaded environment by the time you loop around: you might close the wrong file. In a single-threaded environment, you should expect EBADF immediately after the EINTR, I suppose.
(Log in to post comments)
When the programmer is forced to handle return codes Posted Dec 5, 2009 21:37 UTC (Sat) by nix (subscriber, #2304) [Link]
Yeah, sorry, my attitude about people doing file I/O in many threads at
once is that they deserve everything they get.
I much prefer using processes and explicit IPC to threads.
When the programmer is forced to handle return codes Posted Dec 6, 2009 11:31 UTC (Sun) by hppnq (guest, #14462) [Link] I think the point is that close() will always render the file descriptor unusable: if it doesn't you really cannot close() it again safely, because you've bumped into a kernel bug.
|
|||||||||||||