The return of kevent?
Posted May 17, 2007 20:30 UTC (Thu) by
slamb (guest, #1070)
In reply to:
The return of kevent? by pphaneuf
Parent article:
The return of kevent?
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.
(
Log in to post comments)