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 http://blogs.msdn.com/shrib/archive/2008/05/23/signals-on-windows.aspx 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 Borde 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 (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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde 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 (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
