Signal.trap

Ruby IronRuby
1

After various workarounds, I can now run the rails app to the point that
it gets through all of the gems infrastructure and starts running actual
rails specific code.

Unfortunately the first thing that it calls is Signal.trap which is
currently unimplemented.

I have an implementation of Signal.trap from Ruby.NET but it relies on
Pinvoke to call functions in msvcrt

How do you feel about this kind of code in IronRuby?

Cheers, Wayne.

2

PInvokes would, of course, make it non-portable to mono…or silverlight
for
that matter. So no, I don’t think it’s a good idea :slight_smile:

3

2008/5/18 Michael L. [email protected]:

PInvokes would, of course, make it non-portable to mono…or silverlight for
that matter. So no, I don’t think it’s a good idea :slight_smile:

Well, Mono supports P/Invoke, and Ruby.NET’s Signal code actually
worked fine on Mono. (In this case, signal() function is portable
between Windows and Unix.)

Silverlight would be problematic indeed. But then, why would Ruby code
in Silverlight use methods in Signal module?

4

What signals are used in Rails and what for?

Tomas

5

AFAICT they use

INT, TERM, HUP, USR1, USR2 (most of them in the fastcgi handler, but
mongrel
and thin use them as well)

thin also uses QUIT

That’s what i got from quickly running grep over my rails gems
I’ve asked koz if I left some out and if I did I’ll let you know which
ones
are missing.

6

I’m not sure I can answer that question in it’s totality as I’m not
familiar with much of the Rails framework. But the examples that I’ve
seen so far have been trapping the SIGINT and/or TERM signals in order
to perform a graceful controlled shutdown.

Cheers, Wayne.

7

Could you please file bugs for all the workarounds you’ve needed (if
they are not filed yet)?
I’ll take a look at Signal#trap tomorrow.

Thanks,
Tomas

8

I can also report that after applying patches and other workarounds, I
have been able to get “require ‘active_record’” to work, and that I have
started playing with a simple activerecord use case. Here are some
issues that I have encountered so far:

(1) Bug #20222: super call in initialize method of a module throws an
exception

  • This bug crops up in the Ruby library ‘logger.rb’
    (2) Ruby library ‘Process’ not implemented -
  • Is anyone working on this? More specifically, the method
    Process::times() is called by the Ruby library ‘benchmark.rb’.
    Implementing this would also require an implementation of Struct::Tms.
    (3) Missing method Signal.trap
  • Wayne has also encountered this issue. In my case Signal.trap is
    needed by active_record/transactions.rb.

More will be coming soon as I apply patches and workarounds…

Cheers,
Brian

On Sun, 18 May 2008 22:23:02 +1000, “Wayne K.” [email protected]
said:

9

From: Tomas M. [[email protected]]
Sent: Monday, 19 May 2008 5:39 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

Could you please file bugs for all the workarounds you’ve needed (if they are not filed yet)?

I’ve submitted all that make sense to submit at this stage.
Others that result from patches on top of uncomfirmed patches are best
not to submit yet as it’s not always clear where the bug actually lies.

The most pressing issue for me at this stage is that of internal file
path representation ‘/’ vs ‘’ (from my previous email).

Any initial thoughts?

I suspect we will find less resistence if we go with ‘/’ as there’s a
lot of gems code that explicitly uses ‘/’

Cheers, Wayne.

10

Brian Blackwell:

Process::times() is called by the Ruby library ‘benchmark.rb’.
Implementing this would also require an implementation of
Struct::Tms.
(3) Missing method Signal.trap

  • Wayne has also encountered this issue. In my case Signal.trap is
    needed by active_record/transactions.rb.

  1. I believe that 20222 is fixed in the next release

  2. Curt is working on an implementation of Struct#tms this morning.

  3. Tomas will work on Signal#trap.

We’re running behind in getting a new release out since we had a few
interdependent shelvesets that we had to get past the troll. Once we
review Tomas’ latest changes (Yaml) this morning we’ll post a new
release that should fix most known issues.

Thanks,
-John

11

Do signals work well with managed code? When a signal is raised, the OS
freezes whatever the thread was doing and runs the handler.
http://msdn.microsoft.com/en-us/library/xdkz3x12(VS.71).aspx lists a
number of restrictions that the handler needs to follow. It does not say
anything about managed code specifically. But you are not supposed to
use heap routines, and running IronRuby code will almost definitely
allocate objects under the hood. Also, if the managed handler triggers a
GC or a stack-walk for some other reason, it could lead to problems if
the thread was originally in an uninterruptible state.

Wayne, did Ruby.Net have good tests around Signal? I wonder if Signal
can actually be well supported in IronRuby, or if its going to be a
fragile API.

The same problems would apply to MRI or other runtimes where the user is
not in full control of the actual processor instructions that get
executed as part of the handler. However, MRI is probably a simpler
system than the CLR and less susceptible to the kinds of problems
mentioned above.

We could support some of the well-known signals by mapping them directly
to .NET paradigms. SIGNINT can be handled by using
Console.CancelKeyPress
(Console.CancelKeyPress Event (System) | Microsoft Learn).
SIGTERM can be built on top of AppDomain.ProcessExit
(AppDomain.ProcessExit Event (System) | Microsoft Learn)
or AppDomain.DomainUnload
(AppDomain.DomainUnload Event (System) | Microsoft Learn).

For other signals like USR1 and USR2, we can implement stub functions
for Signal#trap that does no real work. So Ruby code that calls
Signal#trap will not fail right away, and things will work as long as no
one calls Process.kill. IronRuby may end up not using fastcgi, and so we
may not need all of these handlers anyway.

For RailsConf, I think we should just stub out Signal#trap, and then
later discuss a real plan for signals. John, Tomas, does this sound like
a reasonable plan?

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx?
Visit IronPython Blog | Microsoft Learn

From: [email protected]
[mailto:[email protected]] On Behalf Of Ivan Porto
Carrero
Sent: Sunday, May 18, 2008 5:39 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

AFAICT they use

INT, TERM, HUP, USR1, USR2 (most of them in the fastcgi handler, but
mongrel and thin use them as well)

thin also uses QUIT

That’s what i got from quickly running grep over my rails gems
I’ve asked koz if I left some out and if I did I’ll let you know which
ones are missing.

On Mon, May 19, 2008 at 12:11 PM, Wayne K.
<[email protected]mailto:[email protected]> wrote:

I’m not sure I can answer that question in it’s totality as I’m not
familiar with much of the Rails framework. But the examples that I’ve
seen so far have been trapping the SIGINT and/or TERM signals in order
to perform a graceful controlled shutdown.

Cheers, Wayne.

Tomas

PInvokes would, of course, make it non-portable to mono…or
–
Seo S.

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

12

I think the right way to implement Ruby signals is as follows:

· Signal#trap results in a low level handler in IronRuby being
registered for the signal. IronRuby remembers the block argument and the
signal number in a side-table.

· When the signal is raised, the low level handler will get
fired. This handler might need to be a Constrained Execution Region
(Constrained Execution Regions | Microsoft Learn)

· The handler will need to set up a new thread, just like “Win32
operating systems generate a new thread to specifically handle that
interrupt” as described at
http://msdn.microsoft.com/en-us/library/xdkz3x12(VS.71).aspx for SIGINT.

· When the new thread runs, it can look up the side-table and
run the corresponding block. At that point, there are no restrictions on
what the block can do.

Basically, just like Console.CancelKeyPress provides a safe way to
handle SIGINT, we will need to build a general mechanism for processing
arbitrary signals in a safe way. Ideally, the CLR would do this for us.
Something like a “Process.OnSignalRaised”.

Clearly, this is a lot of work. So stubbing out Signal#trap for now
sounds like the way to go.

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx?
Visit IronPython Blog | Microsoft Learn

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Wednesday, May 21, 2008 12:00 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

Do signals work well with managed code? When a signal is raised, the OS
freezes whatever the thread was doing and runs the handler.
http://msdn.microsoft.com/en-us/library/xdkz3x12(VS.71).aspx lists a
number of restrictions that the handler needs to follow. It does not say
anything about managed code specifically. But you are not supposed to
use heap routines, and running IronRuby code will almost definitely
allocate objects under the hood. Also, if the managed handler triggers a
GC or a stack-walk for some other reason, it could lead to problems if
the thread was originally in an uninterruptible state.

Wayne, did Ruby.Net have good tests around Signal? I wonder if Signal
can actually be well supported in IronRuby, or if its going to be a
fragile API.

The same problems would apply to MRI or other runtimes where the user is
not in full control of the actual processor instructions that get
executed as part of the handler. However, MRI is probably a simpler
system than the CLR and less susceptible to the kinds of problems
mentioned above.

We could support some of the well-known signals by mapping them directly
to .NET paradigms. SIGNINT can be handled by using
Console.CancelKeyPress
(Console.CancelKeyPress Event (System) | Microsoft Learn).
SIGTERM can be built on top of AppDomain.ProcessExit
(AppDomain.ProcessExit Event (System) | Microsoft Learn)
or AppDomain.DomainUnload
(AppDomain.DomainUnload Event (System) | Microsoft Learn).

For other signals like USR1 and USR2, we can implement stub functions
for Signal#trap that does no real work. So Ruby code that calls
Signal#trap will not fail right away, and things will work as long as no
one calls Process.kill. IronRuby may end up not using fastcgi, and so we
may not need all of these handlers anyway.

For RailsConf, I think we should just stub out Signal#trap, and then
later discuss a real plan for signals. John, Tomas, does this sound like
a reasonable plan?

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx?
Visit IronPython Blog | Microsoft Learn

From: [email protected]
[mailto:[email protected]] On Behalf Of Ivan Porto
Carrero
Sent: Sunday, May 18, 2008 5:39 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

AFAICT they use

INT, TERM, HUP, USR1, USR2 (most of them in the fastcgi handler, but
mongrel and thin use them as well)

thin also uses QUIT

That’s what i got from quickly running grep over my rails gems
I’ve asked koz if I left some out and if I did I’ll let you know which
ones are missing.
On Mon, May 19, 2008 at 12:11 PM, Wayne K.
<[email protected]mailto:[email protected]> wrote:

I’m not sure I can answer that question in it’s totality as I’m not
familiar with much of the Rails framework. But the examples that I’ve
seen so far have been trapping the SIGINT and/or TERM signals in order
to perform a graceful controlled shutdown.

Cheers, Wayne.

Tomas

PInvokes would, of course, make it non-portable to mono…or
–
Seo S.

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

13

Some more followup. On Windows, raise
(http://msdn.microsoft.com/en-us/library/dwwzkt4c(VS.71).aspx) can only
send a signal to the same process synchrously on the same thread. If you
do “Process.kill” with MRI running on Windows, it only works if you send
a signal to the same process. It does not work if you try to send a
signal to a different process.

Python signals also only work on *nix. “os.kill” is only available on
*nix according to http://www.python.org/doc/2.4/lib/os-process.html.

So the only way signals could be used in IronRuby in a portable fashion
is to use them to deal with Ctrl-C as that is the only useful subset
that will work on Windows. I have attached sample code at

if anyone wants to play with it.

Thanks,
Shri
Want to work on
IronRuby?http://members.microsoft.com/careers/search/details.aspx?JobID=7C2E33E8-5A9C-44F3-A1CE-DA2D66DC3C8B
http://members.microsoft.com/careers/search/details.aspx?JobID=7C2E33E8-5A9C-44F3-A1CE-DA2D66DC3C8B

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Wednesday, May 21, 2008 12:40 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

I think the right way to implement Ruby signals is as follows:

· Signal#trap results in a low level handler in IronRuby being
registered for the signal. IronRuby remembers the block argument and the
signal number in a side-table.

· When the signal is raised, the low level handler will get
fired. This handler might need to be a Constrained Execution Region
(Constrained Execution Regions | Microsoft Learn)

· The handler will need to set up a new thread, just like “Win32
operating systems generate a new thread to specifically handle that
interrupt” as described at
http://msdn.microsoft.com/en-us/library/xdkz3x12(VS.71).aspx for SIGINT.

· When the new thread runs, it can look up the side-table and
run the corresponding block. At that point, there are no restrictions on
what the block can do.

Basically, just like Console.CancelKeyPress provides a safe way to
handle SIGINT, we will need to build a general mechanism for processing
arbitrary signals in a safe way. Ideally, the CLR would do this for us.
Something like a “Process.OnSignalRaised”.

Clearly, this is a lot of work. So stubbing out Signal#trap for now
sounds like the way to go.

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx?
Visit IronPython Blog | Microsoft Learn

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Wednesday, May 21, 2008 12:00 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

Do signals work well with managed code? When a signal is raised, the OS
freezes whatever the thread was doing and runs the handler.
http://msdn.microsoft.com/en-us/library/xdkz3x12(VS.71).aspx lists a
number of restrictions that the handler needs to follow. It does not say
anything about managed code specifically. But you are not supposed to
use heap routines, and running IronRuby code will almost definitely
allocate objects under the hood. Also, if the managed handler triggers a
GC or a stack-walk for some other reason, it could lead to problems if
the thread was originally in an uninterruptible state.

Wayne, did Ruby.Net have good tests around Signal? I wonder if Signal
can actually be well supported in IronRuby, or if its going to be a
fragile API.

The same problems would apply to MRI or other runtimes where the user is
not in full control of the actual processor instructions that get
executed as part of the handler. However, MRI is probably a simpler
system than the CLR and less susceptible to the kinds of problems
mentioned above.

We could support some of the well-known signals by mapping them directly
to .NET paradigms. SIGNINT can be handled by using
Console.CancelKeyPress
(Console.CancelKeyPress Event (System) | Microsoft Learn).
SIGTERM can be built on top of AppDomain.ProcessExit
(AppDomain.ProcessExit Event (System) | Microsoft Learn)
or AppDomain.DomainUnload
(AppDomain.DomainUnload Event (System) | Microsoft Learn).

For other signals like USR1 and USR2, we can implement stub functions
for Signal#trap that does no real work. So Ruby code that calls
Signal#trap will not fail right away, and things will work as long as no
one calls Process.kill. IronRuby may end up not using fastcgi, and so we
may not need all of these handlers anyway.

For RailsConf, I think we should just stub out Signal#trap, and then
later discuss a real plan for signals. John, Tomas, does this sound like
a reasonable plan?

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx?
Visit IronPython Blog | Microsoft Learn

From: [email protected]
[mailto:[email protected]] On Behalf Of Ivan Porto
Carrero
Sent: Sunday, May 18, 2008 5:39 PM
To: [email protected]
Subject: Re: [Ironruby-core] Signal.trap

AFAICT they use

INT, TERM, HUP, USR1, USR2 (most of them in the fastcgi handler, but
mongrel and thin use them as well)

thin also uses QUIT

That’s what i got from quickly running grep over my rails gems
I’ve asked koz if I left some out and if I did I’ll let you know which
ones are missing.
On Mon, May 19, 2008 at 12:11 PM, Wayne K.
<[email protected]mailto:[email protected]> wrote:

I’m not sure I can answer that question in it’s totality as I’m not
familiar with much of the Rails framework. But the examples that I’ve
seen so far have been trapping the SIGINT and/or TERM signals in order
to perform a graceful controlled shutdown.

Cheers, Wayne.

Tomas

PInvokes would, of course, make it non-portable to mono…or
–
Seo S.

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core