5 ms·

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

by majke 12y ago

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.

caf 12y ago
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.
general_failure 12y ago
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.
- rurounijones 12y ago
  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"
  - lucozade 12y ago
    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...
    - taejo 12y ago
      > 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 https://hackage.haskell.org/package/tardis
      - lucozade 12y ago
        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.
        steveklabnik 12y ago
        Wouldn't you do the same if you had a time machine?
- anuragbiyani 12y ago
  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."
noselasd 12y ago
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 http://man7.org/linux/man-pages/man7/signal.7.html

by majke 12y ago

caf 12y ago

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.

general_failure 12y ago

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.

rurounijones 12y ago
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"
- lucozade 12y ago
  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...
  - taejo 12y ago
    > 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 https://hackage.haskell.org/package/tardis
    - lucozade 12y ago
      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.
      - steveklabnik 12y ago
        Wouldn't you do the same if you had a time machine?
anuragbiyani 12y ago
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."

noselasd 12y ago

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 http://man7.org/linux/man-pages/man7/signal.7.html