3 ms·

revoke() is potentially harmful, since an application not written to check the error code after each interaction with each file descriptor will break when one o

by jude- 12y ago

revoke() is potentially harmful, since an application not written to check the error code after each interaction with each file descriptor will break when one of its file descriptors is revoke()'ed out from under it. Why not instead use fuser(1) to find programs using the file descriptor you want closed, and then take program-specific actions (kill(1), restart, signal) to ensure that they sanely release the descriptor?

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 ago
  I 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 ago
    You 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 ago
      We 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 ago
        revoke() 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".

by jude- 12y ago

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 ago
I 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 ago
  You 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 ago
    We 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 ago
      revoke() 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".