They are an implementation detail; used to manipulate the request and response from ruby (see later on down in the massive handle method). In my forks "rackupdate" branch I don't think they exist anymore, as I'm refactoring that code a bit.
~Jimmy Sent from my phone On Oct 8, 2009, at 11:12 AM, "Nathan Stults" <nathan_stu...@hsihealth.com > wrote: > Good news, thanks. In the Handle method of the IIS.cs, you are setting > two scope variables, __request and __response - are these variables > known to Rack, or are those set for the convenience of a IronRuby > adapter aware programmer to use from ruby if desired? > > Thanks, > > Nathan > > -----Original Message----- > From: ironruby-core-boun...@rubyforge.org > [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy > Schementi > Sent: Thursday, October 08, 2009 12:54 AM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > That lock is there because Rails wasn't thread-safe at the time of > writing; it has no reflection on whether ScriptEngine is thread- > safe. I > believe ScriptEngine is thread-safe, as only one ScriptEngine per > language can EVER exist when you have only one ScriptRuntime. > > Rails is much more thread-safe than it used to be, so that lock should > be removed; IMO it should have never been there as the Rack adapter > shouldn't care about Rails; it should lock if the rack.multithreaded > flag is true. > > ~js > ________________________________________ > From: ironruby-core-boun...@rubyforge.org > [ironruby-core-boun...@rubyforge.org] on behalf of Nathan Stults > [nathan_stu...@hsihealth.com] > Sent: Thursday, October 08, 2009 12:26 AM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > Ahh nice clean, brief code. Now this I can handle. I do have a > question > though about threading - it looks like in your implementation the > whole > apparatus is essentially single threaded, i.e. there is a single > handler > maintained by the factory, and the single handler locks itself for the > duration of the request - this suggests to me that ScriptEngine (or at > least RubyEngine) is not thread-safe? Is that the case, or was the > threading designed for simplicity? For instance, if in my > implementation > I took a lock on the RubyEngine just long enough to obtain a new scope > to handle the request, would that do? Or does it pretty much need to > be > 1 thread = 1 script engine? If the latter is the case, would there be > any caveats to maintaining a small pool of engines that could handle a > few simultaneous requests? To be honest, this almost certainly won't > make a bit of difference to my use case of embedding a web server in > an > application server, traffic just won't be that high, but mostly I'm > just > curious about the platform. > > Thanks, > > Nathan > > -----Original Message----- > From: ironruby-core-boun...@rubyforge.org > [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy > Schementi > Sent: Wednesday, October 07, 2009 5:12 PM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > The HttpHandler is the only piece you'll have to replace, since it's > specifically for IIS, and provide your own hookup to the server you > choose. You'll have to construct the HttpRequest/Response objects > also, > but all-in-all it should be pretty straight-forward. Those two look > like > great .NET web-server projects; "webserver" is like a web-framework > too, > which is cool. Whatever you do, DON'T use Chiron, as it's not intended > to be a real web-server (it doesn't support POST requests, and only > listens on localhost). > > ~js > >> -----Original Message----- >> From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core- >> boun...@rubyforge.org] On Behalf Of Nathan Stults >> Sent: Wednesday, October 07, 2009 4:54 PM >> To: ironruby-core@rubyforge.org >> Subject: Re: [Ironruby-core] Native Extensions >> >> I spent a day chasing my tail and, upon catching it, realized my > DLR/IronRuby >> knowledge just isn't up to the challenge. Maybe someday. As an > alternative, >> I'm going to see if the IronRuby.Rack stuff on Git can teach me >> what I > need to >> wire Rack up to one of these embeddable .NET HTTP servers: >> http://www.codeplex.com/webserver, >> http://runkayak.com/getstarted, which ought to provide the same > benefit, >> and possibly perform a little better as well. Is anyone aware of >> other >> embeddable .NET HTTP server projects? >> >> (http://github.com/jschementi/ironruby/tree/ >> 92932a672921a03210c8aefe23 >> ac >> 0a7d6996ed2d/Merlin/Main/Hosts/IronRuby.Rack) >> >> >> -----Original Message----- >> From: ironruby-core-boun...@rubyforge.org >> [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Daniele >> Alessandri >> Sent: Tuesday, October 06, 2009 11:39 PM >> To: ironruby-core@rubyforge.org >> Subject: Re: [Ironruby-core] Native Extensions >> >> Hi Nathan, >> yes, that's basically what you need to do: >> >> 1- rewrite the C (or Java) bits of the http parser in C# and let >> Ragel > generate >> the rest >> 2- wrap everything up in a layer to expose the needed methods to > IronRuby >> 3- make sure to require your newly built http11.dll in the ruby part > of the >> mongrel library >> 4- have fun. >> >> I did the same for hpricot and json (whose parsers are generated >> using >> Ragel), so I guess that should work for Mongrel too :-) >> >> >> On Wed, Oct 7, 2009 at 03:09, Nathan Stults > <nathan_stu...@hsihealth.com> >> wrote: >>> Thanks for the tip. It looks like the Http Parser is generated via >>> Ragel, and it appears there is a Java version of the language file, > so >>> theoretically all I should have to do is learn Ragel and port that >> file >>> to C#, piece of cake :) Then I suppose I'd need a patched version of >>> mongrel that required the new .NET HTTP parser dll instead of the C >>> version? Is that how that would work? >>> >>> -----Original Message----- >>> From: ironruby-core-boun...@rubyforge.org >>> [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy >>> Schementi >>> Sent: Tuesday, October 06, 2009 6:00 PM >>> To: ironruby-core@rubyforge.org >>> Subject: Re: [Ironruby-core] Native Extensions >>> >>> Native extension support is not on the roadmap for 1.0. Win32OLE >> support >>> is actually in there now, because of the Dynamic Language Runtime's >>> support for dispatching to COM objects. So IronRuby's version of >>> win32ole.rb uses IronRuby's OLE support, rather than depending on >> native >>> code. >>> >>> The current work-around for libraries which use native code to >>> communicate with the OS or Ruby is to rewrite those using .NET so >>> IronRuby can use them. Mongrel is actually \mostly Ruby code, as > most >>> Ruby libraries which use native code; there is usually a very small >> part >>> of the library which depends on native code. For Mongrel, the HTTP > 1.1 >>> parser is the only native piece; rewriting that in C# would allow > you >> to >>> run Mongrel on .NET. >>> >>> IMO, after 1.0 would be the time to consider supporting the native >> Ruby >>> API. >>> >>> ~Jimmy >>> ________________________________________ >>> From: ironruby-core-boun...@rubyforge.org >>> [ironruby-core-boun...@rubyforge.org] on behalf of Nathan Stults >>> [li...@ruby-forum.com] >>> Sent: Tuesday, October 06, 2009 4:18 PM >>> To: ironruby-core@rubyforge.org >>> Subject: [Ironruby-core] Native Extensions >>> >>> I noticed on the road-map this item under .NET Interop: >>> >>> [P3] COM: for Win32OLE compatibility >>> >>> Is that the same thing as supporting native extensions? If not, is > it >> on >>> the roadmap to support such a thing? Also, is there a workaround, > like >>> replacing files in the gem installation with a .NET wrapper? I'd > love >> to >>> use IronRuby to embed Thin or Mongrel in my .NET services, but from >> from >>> my few experiments it looks like most of the networking libraries >> these >>> servers use tend to rely on native dll's. >>> -- >>> Posted via http://www.ruby-forum.com/. >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> >> >> >> -- >> Daniele Alessandri >> http://www.clorophilla.net/blog/ >> http://twitter.com/JoL1hAHN >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core@rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core@rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
