^C (SIGINT) doesn't interrupt the cocoa runloop

[lsansonetti@…]

Start a MacRuby example, then hit ^C. The program is not interrupted, and still continues, which is not expected.

Manually sending INT using kill(1) produces the same effect.

[lsansonetti@…]

http://www.ruby-forum.com/topic/145060#new

[lsansonetti@…]

http://www.ruby-forum.com/topic/145062#new

[pantarei@…]

This is fixed in ruby 1.9 revision 15869.

[lsansonetti@…]

Should be fixed in trunk, closing.

[z@…]

I just built from trunk revision 202, and ^{C still seems unable to interrupt the run loop.}

[z@…]

^C

[z@…]

Bah. SIGINT doesn't interrupt :)

[lsansonetti@…]

Indeed, looks like SIGINT doesn't immediately interrupt the runloop, but only during the next runloop iteration. It's still better than before, but it's clearly not fixed yet.

[lsansonetti@…]

After a quick investigation, it seems that the signal is intercepted by the default handler but not forwarded to YARV because the runloop blocks the main thread without calling RUBY_VM_CHECK_INTS. This theoretically be fixed if we set up a timer in the main run loop that checks for interruptions.

[lsansonetti@…]

Implemented in r212. Periodically calling RUBY_VM_CHECK_INTS every 0.1s. Checked that this is only performed in a CF runloop environment (e.g. not by default) and that the timer has no performance impact (around 0.5% CPU time).