On the other hand, signalfd is kind of wonderful, and it's not like FreeBSD is about to suddenly experience a renaissance.

Feeding a troll ... may not be my smartest move yet.

Yes, signalfd() is wonderful and nice, but it makes it a pain in the behind to port your software. If you need to use signals and do it in an event loop of some sort take a look at libev which abstracts away the OS and handles it in the best way possible depending on the system it is run on.

Not only that, but libev will make use of epoll/kqueue/select/poll as required on the OS it is running on, so you get easier portability with the various different event mechanisms that do exist across systems.

I understand that signalfd() is unportable, the question is, why port?

Many people do still want to run FreeBSD, and it may not be you the original developer that has to port it, but the ports maintainer that puts it in the FreeBSD ports tree, or a company that already has everything running on top of FreeBSD (think Yahoo) wants to use the software, now they have to take the time to port your Linux only code, when using standard POSIX compliant code would have made it much simpler, possibly as simple as a ./configure && make rather than introducing extra work.

Why limit your audience to one single operating system?

OS X, however?

It's not particularly hard to emulate (most of) signalfd()'s behavior by writing a byte to a pipe and checking for it in your main loop.

Er, no, thank you, I very much do not mean iOS. I mean OS X, which, irrespective of your (obnoxiously communicated) opinion of it, is rather popular amongst Unix developers and it tends to be a good idea to write your Unix code to support it.