Hacker News Reader

Comment by majke | Hacker News Reader

I still don't understand how queueing signals works.

For example, signalfd() is really cool, and you can indeed read() a signal from it, but only one of a kind.

If you get, say, two SIGINT's you may as well just be able to read() one. I guess it's an implementation detail that some signals aren't queued while some others are, I guess. In practice it means that receiving a signal is an edge, and in signal handler you must check how many times the signal occurred. This for me sounds inherently racey.

View on HN

You don't check how many times the signal occured - you write your code so that it doesn't matter how many times the signal occured.

For example, when you're handling a SIGCHLD you don't assume exactly one child has exited - you loop around calling waitpid() with WNOHANG and handle every child that's exited.

Note that the standard signals are not queued, a signal handler for a specific signal might be run just once if several signals are sent between the first signal arriving and the signal being handled.

As an extension, there are "real-time" signals as well, which are queued - linux implement them, see e.g. http://man7.org/linux/man-pages/man7/signal.7.html

What's a good use case for knowing how many times a signal was raised? Signal once raised has no more context than the signal itself.

If the signal is received more than once it means it is more important :p

"Oh shit!"

"^C^C^C^C^C^C~C^C"

In my experience it usual means that you need some form of time reversal e.g. unsend an email or put a BEGIN TRAN before the SQL you just executed.

Reasonably sure that can't be done in C even with all that undefined behaviour.

However, if your IO monad implementation is sufficiently slow, you could ^C between when you thought the code had executed and when it actually bothered to get around to it.

I can't believe that none of the functional ninjas thought to add time travel as a benefit. Most remiss...

> I can't believe that none of the functional ninjas thought to add time travel as a benefit. Most remiss...

Ahem: https://hackage.haskell.org/package/tardis

With much delight, I stand corrected.

Haskell perpetually astonishes me. Not only is it, more or less single-handedly, keeping the Holy Wars alive, it now appears to supply punchlines to jokes. Amazing.

Wouldn't you do the same if you had a time machine?

Although I cannot recall any specific name right now, I have certainly seen programs handling a single Ctrl-C different than say two Ctrl-C in quick succession.

Example: Pressing one Ctrl-C will display a message like this on some programs (which do not want to terminate themselves upon receiving a single SIGINT, because accidents happen): "Press Ctrl-C again to quit."

Reply on news.ycombinator.com