From: "Iñaki Baz Castillo" Date: 2012-05-01T02:13:16+09:00 Subject: Re: What is the meaning of rb_thread_interrupted() ? 2012/4/29 Eric Wong : >> Try Ruby Cross Reference -- it uses ctags inside and has full-text >> search. >> >>    http://rxr.whitequark.org/ > > (warning: I don't like using websites in general :) > > Accessing the source code directly is much more helpful IMNSHO.  Iñaki > can easily change the code locally, and run it to see how it behaves and > whether or not it matches his assumptions (based on just reading code). > He can also utilize tracing tools when he's building/running it. Hi both, thanks a lot. I really appreciate the help of Eric and, for sure, he is 200% right. But being honest, the HTTP link provided by Peter is useful (until I dominate the world with console tools that examinate About my specific question: I couldn't find a good usage example code of rb_thread_interrupted(). I found it in io.c but that is very very complex code (at least for me). Well, let me explain what I want to achieve: I'm coding a Ruby event library "framework" (like EventMachine) using libuv. It creates a C loop (uv_loop) that handles events. For entering into the C loop I call it with rb_thread_call_without_gvl(), and when some event takes place, I execute the associated Ruby callback by calling it with rb_thread_call_with_gvl(). It works, so I can run other Ruby threads at the same time. Now I want to handle received signals. And I *already* have the needed code to make it to work perfectly, no issues at all, but maybe it's not the mos efficient solution: In the uv_loop I add a "uv_prepare" event which is a callback to be executed before each loop iteration. In this callback I call to: rb_thread_call_with_gvl(rb_thread_check_ints, NULL); So if a signal has been received, then let Ruby land to handle it (for example the user could use Ruby trap(){ } method to handle it). The exact code is here: https://github.com/ibc/AsyncEngine/blob/master/ext/asyncengine/asyncengine_ruby.c#L61 As said before, it works "perfectly" (no issues found for now), but in case I add (for example) a periodic timer to be executed every 1 miliseconds by UV, then such a callback is executed every 1 milisecond, which involves calling to "rb_thread_call_with_gvl(rb_thread_check_ints, NULL);". Maybe it is not efficient and I could check in some other way whether there are received signals before calling to rb_thread_check_ints() ? Initially I figured out that rb_thread_interrupted() (which can be called safely in the blocking region) would be what I'm looking for, but I think it's not (since it just does not work). So any help on this "complex" stuf? Thanks a lot. -- Iñaki Baz Castillo