From: Richard Kilmer <rich@...>
Date: 2003-08-04T07:56:24+09:00
Subject: Re: Too bad I've found about Ruby

Ruby handles network traffic great in its internal threading model.  It 
uses non-blocking IO, so performing network related downloads in the 
background works great.  I wrote the Jabber client API for Ruby and it 
uses a background Ruby thread connected to a TCP socket to stream the 
Jabber XML over the network...works like a charm.  The issue you will 
run into with Ruby threads and native user interfaces is that most 
native GUIs expect multiple threads (for the message pump, etc).  
FXRuby and VRuby/SWin handle this by yielding to the Ruby interpreter 
during free cycles (or via a timer)...but this may be a problem...

...another choice is to build a web-based user interface (or 
Flash-based) that is delivered by an in-machine Ruby web service...and 
have that Ruby web service have all the business logic in it (kind of 
in-machine n-tier architecture).  If you wanted it to "look native" you 
could wrap the IE control (or Flash control) in a native window (so you 
get title bars, etc) but the interior of the window is cross-platform 
content/behavior. Just a crazy thought :-)

-rich

On Sunday, August 3, 2003, at 05:48  PM, wit wrote:

> Yes, I'm aware of that. It really worries me, because my application
> will need to be multithreaded. Users must be able to use it online
> with real-time data feed.
> It my be a showstopper for me.
> Is it possible to create Ruby (maybe with some C code) multithreaded
> application on Win32 without blocking the whole app. when
> waiting for/sending data over http?