Do your self a favor and take some time to read:

http://citeseer.ist.psu.edu/schmidt95using.html

And think again about Threaded/Non-blocking I/O.

Keep in mind the "Four Horsemen of Poor Performance":

   1. Data copies
   2. Context switches
   3. Memory allocation
   4. Lock contention


On Sun, 28 Nov 2004 20:12:52 +0900, Robert Klemme <bob.news / gmx.net> wrote:
> 
> "Mikael Brockman" <mikael / phubuh.org> schrieb im Newsbeitrag 
> news:87pt1zav3o.fsf / igloo.phubuh.org...
> 
> >> Your example is quite special.  Usually, when writing servers that
> >> serve huge chunks of data (like HTTP servers that also serve binary
> >> content, e.g. for download) then the usual (and proper) approach is to
> >> copy the file in chunks.  Nobody writes a server that reads a 1GB file
> >> into memory first before sending it over the line.
> >
> > True.  The files I'm sending are only a couple of megabytes.  Still
> > takes a long time to send to, say, someone on 56K.
> 
> I'm sorry, what do you mean by this?  Typical buffer sizes are usually much
> smaller than "a couple of megabytes" so these files would be sent in chunks,
> too.
> 
> >> Or put another way round: if there was a need for select like IO
> >> handling in Ruby, then I'd assume someone would have come up with a
> >> similar solution already.  I don't know such a solution - so probably
> >> nobody did feel the need yet.
> >
> > Don't I count? :-)
> 
> Well, *apart* from yours of course.
> 
> >  There's another project called IO::Reactor[1], but
> > it doesn't do the callcc jig.
> >
> > Footnotes:
> > [1]  http://www.deveiate.org/code/IO-Reactor.html
> 
> Ah, didn't know that one.  Thanks for the pointer!  As far as I can see that
> solution does work with chunks also - and usage looks quite complicated.
> Did you find any information about performance (or other) comparisons of
> IO::Reactor vs. threaded IO?
> 
> Btw, if the only problem is blocking while sending huge chunks of data, then
> what *I* would do is this: I'd override send() (and others that might be
> necessary) to do just that.  Then one can still use the simple threaded
> approach and does not have to care about thread blocking. (Maybe this should
> even be part of the std lib's socket implementation?)
> 
> Kind regards
> 
>     robert
> 
>