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