In what situation does one opens files in rapid succession, without a sockets being more or less involved at the same time? Consider that open() itself is synchronous and blocking, and you've already got a good bit of overhead. If you start thinking about an "async open", then I'll refer you to this.
I would remind you that a big way to decrease the overhead of event handling is to have less events in the first place, thus the usefulness of interest sets and such (think of X11's event_mask, as on a remote display, event dispatching can be slow). At some point, you'll have to make a syscall to tell the kernel if yes or no you want events for a given file descriptor. At best, it could be specified through flags when opening, but I don't think this is an issue worth addressing.
I think what Ulrich was referring to was more when you want to "fiddle" with the interest set rather frequently. For example, picture a user-space port forwarder, where it starts waiting for readability on both sockets, but upon receiving a packet, will add writability of the other socket to its interest set (maybe remove readability of the socket where the packet arrived, for flow control), etc...
This particular situation is a case where edge-triggered events (well supported by epoll, by the way) are indicated, as you can set the interest set of both sockets to read and write, and leave them as-is, keeping track of the state of the sockets in user-space.
Lastly, what other "local events" are there?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds