The thing is, if I had that extra information in my abstraction, then I'd have to have some special "I don't know" value for select/epoll, test for that, slightly different behaviour between epoll and kqueue, etc... So I just don't really find it worth the trouble, at the moment. But I'm open to the idea that I might be missing something...
One thing is that not everyone cares about writing portable code. I used to always write everything in this way (don't use fancy features or don't depend on them), but a few things started to change my mind. One of them was reading this story. Another was starting to work on a BSD-based proprietary system. We have the make world style - a single source tree, no collection of RPMs with tarballs and patches. We can add libraries, daemons, and kernel extensions that the rest of the system depends on. We don't use autoconf-based fallback code or lowest-common denominator abstraction layers. We've given up on the idea of sending most of our changes upstream, so we do what works for us. It can be liberating to say "screw portability/ compatibility". It's much easier to do on our system where you can make a single changeset that modifies everything you need and be certain one piece will never run on a real system without the other.
Now I'm ready to take the same attitude to other code that I write. Portability isn't a hard requirement; it's something to be kept as long as it doesn't hold me back too much. Code doesn't run on Python 2.2? Who cares?!? I run mostly CentOS 5, which has Python 2.4, so I'll take advantage of the newer language features. Code doesn't run without epoll_wait() or kevent()? Who cares?!? I use systems with modern kernel interfaces. Code doesn't run without a Linux-only kernel interface? Maybe I'll add it or something equivalent to BSD if I want to run it there.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds