3 ms·
FWIW, printf() is not async-signal-safe. It's bad form to call such routines from within a signal handler. Here's a list of async-signal-safe functions (scrol
by smcdow 15y ago
FWIW, printf() is not async-signal-safe. It's bad form to call such routines from within a signal handler.
Here's a list of async-signal-safe functions (scroll down): http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh...
I know I'm missing the point of the post, but it is a particular nit that I pick. You'd be surprised at how often this happens in production code, and how often it causes mysterious, hard-to-reproduce bugs.
- nkurz 15y agoI don't disagree with your logic, but how would you recommend that he solve this in a safer manner? Fork() and printf()? Ignore signals before printf()? Use write()? Some other manner of triggering besides Ctrl-C?
- smcdow 15y agoI'd keep an int flag, initialized to zero. The sighandler sets the flag. The flag is checked (and reset) on entry to newCoin(). Not exactly pretty, but using signals to trigger to produce reports isn't exactly pretty either. Unfortunately, signals are often abused in this manner. Not a big deal for such for this small piece of software, but in larger systems this kind of abuse can cause very hard to fix bugs.
- cperciva 15y agoI'd keep an int flag, initialized to zero. If you do, your code is buggy: sig_atomic_t is the only type you can safely use inside and outside a signal handler.
- smcdow 15y agoPlease explain why this would be true for single-threaded applications.
- vonuebelgarten 15y agoBecause your signal handler may get interrupted by another signal.
- smcdow 15y agoSo what? Even then, there will be no concurrency issues in a single threaded application.
- smcdow 15y agoA (possibly) cleaner way would be to use Boost.asio. I haven't yet evaluated the POSIX Signal handing part of Boost.asio, but I'm hopeful that it will be useful for my purposes.