FD interface vs memory interface (and signal/timer fd interface)

Posted May 31, 2007 14:33 UTC (Thu) by pflugstad (subscriber, #224)
In reply to: The return of syslets by RobSeace
Parent article: The return of syslets

I agree. Any app that assumes it owns the FD space is just asking to be borked. My first major unix application (in grad school) involved forking and exec'ing another process and using dup and friends to control I/O to it. I learned fast to check return codes and be careful with dup.

I also really like the whole signalfd and timerfd interface. I think it's much cleaner than some kind of memory interface and it fits in really well with FD process loop. I like being able to fold signals and timers into my normal select (or epoll) style interface.

Granted this is probably not a high performance setup, but I think you should always work out the best clean/correct interface, then make it perform fast, vs trying to work out a fast "ugly" interface. Signals and timers have always been the ugly stepchildren in the Unix environment, and this makes them feel more Unix-like. Now, if we could just get System V IPC to interact with FD's as well...

I also like that signalfd and timerfd interfaces would possibly be easily portable to other Unixen and even something like Cygwin (natural fit with win32's WaitFor functions? - I doubt it's even on the Cygwin people's radar at this point though). Just conjecture.