Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Not to Write a Signal Handler

741mhz.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: How Not to Write a Signal Handler

#21

Post by teacup50 »

kev009 wrote: post #18
fafner wrote: post #7

Earlier quoted context omitted.

I think the kqueue interface is a lot worse than the Linux way. With kqueue everything is forced through one interface. In Linux it's just file descriptors and epoll to deal with them. It is a nice extension of the "everything is a file" mechanism and it embodies the "do one thing and do it right". This becomes apparent when you look at fs notifications. You've already mentioned how inotify is superior to kqueue. I m…

There's been talk (at BSDCam) of implementing inotify which is needed for the Linuxulator and exposing it in the FreeBSD API too. So your wish isn't so far fetched but I'm not sure anyone is actively working on it. Patches welcome :)

Would be saner to extend kqueue and hang a Linuxlator inotify compatibility shim off of that; that'd isolate the mess to sys/compat/

Re: How Not to Write a Signal Handler

#23

Post by lelf »

> you might think that people should have came up with something better in terms of signal handling at this time. The truth is that they did

… and then the article goes completely omitting sigqueue+sigwaitinfo (realtime signals)

Re: How Not to Write a Signal Handler

#25

Post by achivetta »

As far as "modern signal handling" goes: On OS X, you can also just create a dispatch source of type DISPATCH_SOURCE_TYPE_SIGNAL. If your code already uses dispatch, this is much easier than trying to wire up to kqueue directly.

Re: How Not to Write a Signal Handler

#26

Post by lmm »

lkrubner wrote: post #4

They write: "It is the 2013th year in the Common Era at the moment of this writing and you might think that people should have came up with something better in terms of signal handling at this time. The truth is that they did. It is just not that well known yet due to a huge momentum of outdated information still overflowing the Internet." Then they talk about kqueue. The above paragraph emphasizes how much Unix prog…

It's been tried. Look at plan 9, or MS Singularity, or heck even BeOS was a clean break in many respects, with certain things implemented at low level and used throughout the OS.

Turns out compatibility and understandability is really useful, and it's good to define your complex systems in terms of simple systems. Worse is better.

Re: How Not to Write a Signal Handler

#27

Post by anuragbiyani »

general_failure wrote: post #14
majke wrote: post #2

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…

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.

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

Re: How Not to Write a Signal Handler

#28

Post by noselasd »

majke wrote: post #2

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…

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

Re: How Not to Write a Signal Handler

#30

Post by lucozade »

rurounijones wrote: post #16
general_failure wrote: post #14

Earlier quoted context omitted.

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

Post reply on HN