[Ironruby-core] Signal.trap

Shri Borde Shri.Borde at microsoft.com
Wed May 21 15:39:42 EDT 2008


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 (http://msdn.microsoft.com/en-us/library/ms228973(VS.85).aspx)

·         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 http://blogs.msdn.com/ironpython/

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, May 21, 2008 12:00 PM
To: ironruby-core at rubyforge.org
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 (http://msdn.microsoft.com/en-us/library/system.console.cancelkeypress.aspx). SIGTERM can be built on top of AppDomain.ProcessExit (http://msdn.microsoft.com/en-us/library/system.appdomain.processexit.aspx) or AppDomain.DomainUnload (http://msdn.microsoft.com/en-us/library/system.appdomain.domainunload.aspx).

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 http://blogs.msdn.com/ironpython/

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Sunday, May 18, 2008 5:39 PM
To: ironruby-core at rubyforge.org
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 Kelly <w.kelly at qut.edu.au<mailto:w.kelly at qut.edu.au>> 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.


> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>
> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
> Tomas Matousek
> Sent: Monday, 19 May 2008 10:00 AM
> To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
> Subject: Re: [Ironruby-core] Signal.trap
>
> What signals are used in Rails and what for?
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>
> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
> Sanghyeon Seo
> Sent: Sunday, May 18, 2008 9:32 AM
> To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
> Subject: Re: [Ironruby-core] Signal.trap
>
> 2008/5/18 Michael Letterle <michael.letterle at gmail.com<mailto:michael.letterle at gmail.com>>:
> > 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 :)
>
> 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?
>
> --
> Seo Sanghyeon
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080521/7b946d81/attachment-0001.html>


More information about the Ironruby-core mailing list