User: Password:
|
|
Subscribe / Log in / New account

When the programmer is forced to handle return codes

When the programmer is forced to handle return codes

Posted 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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds