[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>

Hi, developers,

21 messages 2008/03/01

[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

31 messages 2008/03/03
[#15742] Re: Copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/03/03

Hi,

[#15829] Re: Copy-on-write friendly garbage collector — Daniel DeLorme <dan-ml@...42.com> 2008/03/08

Yukihiro Matsumoto wrote:

[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>

Hello,

18 messages 2008/03/03
[#15759] Re: embedding Ruby 1.9.0 inside pthread — Nobuyoshi Nakada <nobu@...> 2008/03/04

Hi,

[#15760] Re: embedding Ruby 1.9.0 inside pthread — Yukihiro Matsumoto <matz@...> 2008/03/04

Hi,

[#15762] Re: embedding Ruby 1.9.0 inside pthread — "Suraj N. Kurapati" <sunaku@...> 2008/03/04

Yukihiro Matsumoto wrote:

[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>

Hi all,

15 messages 2008/03/04

[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>

I've been reworking JRuby's stdlib to improve performance and fix

10 messages 2008/03/09

[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>

Hi,

35 messages 2008/03/23
[#15991] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#15993] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/23

Hi Dave,

[#15997] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#16024] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

Hi Dave,

[#16025] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16026] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16027] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16029] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16030] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16031] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16032] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:

[#16033] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16041] Re: Recent changes in Range#step behavior — David Flanagan <david@...> 2008/03/26

Dave Thomas wrote:

defect for the signal usage of SIGINT in Ruby 1.9 implementation

From: "Chirag Mistry" <chirag80bece@...>
Date: 2008-03-06 09:52:14 UTC
List: ruby-core #15809
Hi All

I was going through the code of Ruby 1.9. I got some defects related to the
usage of some signal.
Given below are the defect descriptions for the signal usage of SIGINT in
Ruby 1.9 implementation.

Defect Description: Handling SIGINT
"ruby_finalize_1"(In file trunk/eval.c, at line no: 142) function calls
"ruby_sig_finalize function" (In file trunk/signal.c, at line no: 996). In
"ruby_sig_finalize", signal handler SIG_IGN is installed for SIGINT signal
and then signal handler SIG_DFL is installed for SIGINT signal if the
previously installed signal handler was the Ruby handler ("sighandler"). As
per our understanding, it may create problem when ruby interpreter is
embedded in a process for a limited period of time. It should not install
signal handler SIG_IGN for SIGINT signal.

Existing code of ruby_sig_finalize is following:
---------------------------------------------------------------------
void ruby_sig_finalize()
{
    sighandler_t oldfunc;
    oldfunc = ruby_signal(SIGINT, SIG_IGN);
    if (oldfunc == sighandler) {
            ruby_signal(SIGINT, SIG_DFL);
    }
}

We can do below correction in ruby_sig_finalize function:
----------------------------------------------------------------------
void ruby_sig_finalize()
{
    sighandler_t oldfunc;
    oldfunc = ruby_signal(SIGINT, SIG_DFL);
    if (oldfunc != sighandler) {
            ruby_signal(SIGINT, oldfunc);
    }
}

Regards
Chirag

In This Thread

Prev Next