2 ms·
Any interaction with a file descriptor can already fail (eg. pretty much anything can potentially give you EIO). Using fuser() in that way is racy, and how is
by caf 12y ago
Any interaction with a file descriptor can already fail (eg. pretty much anything can potentially give you EIO).
Using fuser() in that way is racy, and how is kill() any better than returning a possibly-ignored error anyway? You can't do program-specific actions because the point is to enforce "You did have permission to open that, but now you don't and you aren't allowed to keep using it".
- moe 12y agoI agree. And actually in my book revoke() is also unnecessary, for the same reason. Why not simply close the fd and let the regular transport error handling (retry/backoff) do its job? If you find yourself needing any more ceremony than that then that almost certainly hints at a higher level mistake in your protocol design.
- caf 12y agoYou can't externally asynchronously close a file descriptor within a process, because of the way file descriptors are re-used. revoke() basically works like closing it on the "other side" - the process still has an open file descriptor, but any IO on it will error.
- moe 12y agoWe may be talking about different things but why would you need to close an fd "externally" when (at least for pipes and sockets) there is someone on the other side who can just close it regularly?
- caf 12y agorevoke() would be useful for things like device nodes (and even regular files) - consider "you can open the sound device while you are logged in locally, but you can't keep using it after you've logged off".