4 ms·

One thing to please keep in mind (knowing that it is called the linux programming blog ...) is that if you program your app around specific Linux only signals/a

by calloc 15y ago

One thing to please keep in mind (knowing that it is called the linux programming blog ...) is that if you program your app around specific Linux only signals/and or methods (aka signalfd) it might be and most likely will be more difficult to port your code to other platforms such as Solaris/BSD/HP-UX/AIX and the like. Having ported my fair share of code from open source projects that only ran on Linux to FreeBSD I feel like too much emphasis is put on using Linux only stuff making it difficult or extremely hard to port code in a clean manner.

krakensden 15y ago
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?

by calloc 15y ago

krakensden 15y ago

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?