Best Practices- USP: Implementing signal handlers - some caveats

Implementing signal handlers - some caveats #ruby

USP: Implementing signal handlers - some caveats 2012-03-27 00:25, written by Eric Wong Signal handlers may run at any time If your program receives a signal, Ruby will invoke the associated signal handler as soon as it is able to. This means a signal handler can hijack your existing code flow just about anywhere in your program (including inside methods of any libraries you use). Normal code execution resumes once the signal handler finishes execution. This is a big difference from most event-driven programming frameworks where callbacks for a given object/event fire synchronously and will not step over existing code flow. Reentrancy vs thread-safety While reentrancy and thread-safety are related concepts, it is absolutely critical to understand is they are NOT the same, and one does not imply the other. (There are existing articles on this, so I won’t dive into this more...

Full article: http://blog.rubybestpractices.com/posts/ewong/016-Impleme...