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?

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

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.

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.

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?

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