Interesting issue.  ISTM that closing the FD before unregistering it is a programmer's mistake that shouldn't pass silently.  And closing it in a separate thread while the selector is active sounds like an even bigger bug.

Could we report an new event type for this situation?  E.g. EVENT_CLOSED.  The proper response would be to unregister the FD.  (And yes, unregistering the FD when it was previously registered should not be an error, even if it has been closed.)

I'm not sure I care that there will be an infinite loop if the caller doesn't take action -- it's the same for any event, if you don't read from an FD when you get an EVENT_READ event, you'll get an infinite loop too.

Note that this is not exactly the same as the "invalid fd" that Victor proposes -- although they aren't always distinguishable, the logic errors in the app are different: in one case, closing a FD (that was valid and registered) without unregistering, in the other case, registering an FD that isn't valid.  (Ideally the register() call should fail, but I suppose we can't detect that without an extra syscall -- although in some cases there's a syscall in register() anyway, and then we can use that to reject the register() call.