Async I/O includes things other than open(), ya know. If it takes longer to deal with the completion of the async_read() than it would to just call read() in the first place, async i/o becomes pointless.
Something that opens lots of files without using sockets: compilers. Consider some auditing system that wants to know every time a file is accessed.
And while sockets may be involved, a web server, news server or IMAP server might open, read, and possibly write a *lot* of files for one socket instance.
As for other local events, consider a piece of shared memory, with a master process that wants to know anytime one of the children writes to it. Yeah, it can be done with an atomic counter and polling, but an event would be much cleaner. And I've had a need for this.
Designing a general kernel events mechanism around the limitations of socket open() seems shortsighted.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds