5 ms·

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

eropple 15y ago
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.
- krakensden 15y ago
  Surely you mean iOS. In which case, I'm not sure why you would be spending much time worrying about signals.
  - eropple 15y ago
    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.
X-Istence 15y ago
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.
- krakensden 15y ago
  I understand that signalfd() is unportable, the question is, why port?
  - calloc 15y ago
    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?

eropple 15y ago

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.

krakensden 15y ago
Surely you mean iOS. In which case, I'm not sure why you would be spending much time worrying about signals.
- eropple 15y ago
  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.

X-Istence 15y ago

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.

krakensden 15y ago
I understand that signalfd() is unportable, the question is, why port?
- calloc 15y ago
  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?