Hacker News Reader

Comment by smcdow | Hacker News Reader

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...

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.

View on HN

I 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?

I'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.

I'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.

Please explain why this would be true for single-threaded applications.

Because your signal handler may get interrupted by another signal.

So what? Even then, there will be no concurrency issues in a single threaded application.

A (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.

Reply on news.ycombinator.com