[Ironruby-core] Signal.trap

Shri Borde Shri.Borde at microsoft.com
Wed May 21 14:59:57 EDT 2008


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/00b4ec7a/attachment-0001.html>


More information about the Ironruby-core mailing list