[Ironruby-core] Native Extensions

Jimmy Schementi Jimmy.Schementi at microsoft.com
Thu Oct 8 14:51:37 EDT 2009


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_Stults at 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-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> Schementi
> Sent: Thursday, October 08, 2009 12:54 AM
> To: ironruby-core at 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-bounces at rubyforge.org
> [ironruby-core-bounces at rubyforge.org] on behalf of Nathan Stults
> [Nathan_Stults at HSIHealth.com]
> Sent: Thursday, October 08, 2009 12:26 AM
> To: ironruby-core at 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-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> Schementi
> Sent: Wednesday, October 07, 2009 5:12 PM
> To: ironruby-core at 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-bounces at rubyforge.org [mailto:ironruby-core-
>> bounces at rubyforge.org] On Behalf Of Nathan Stults
>> Sent: Wednesday, October 07, 2009 4:54 PM
>> To: ironruby-core at 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-bounces at rubyforge.org
>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele
>> Alessandri
>> Sent: Tuesday, October 06, 2009 11:39 PM
>> To: ironruby-core at 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_Stults at 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-bounces at rubyforge.org
>>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
>>> Schementi
>>> Sent: Tuesday, October 06, 2009 6:00 PM
>>> To: ironruby-core at 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-bounces at rubyforge.org
>>> [ironruby-core-bounces at rubyforge.org] on behalf of Nathan Stults
>>> [lists at ruby-forum.com]
>>> Sent: Tuesday, October 06, 2009 4:18 PM
>>> To: ironruby-core at 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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>


More information about the Ironruby-core mailing list