"Robert Klemme" <bob.news / gmx.net> writes:

> "Mikael Brockman" <mikael / phubuh.org> schrieb im Newsbeitrag
> news:87u0rbbb1i.fsf / igloo.phubuh.org...
> > "Robert Klemme" <bob.news / gmx.net> writes:
> >
> >> That said, a solution with threads and blocking IO is still more
> >> elegant IMHO.  It's just that for some circumstances this is not
> >> the right solution.
> >
> > I agree.  What I find inelegant is threads with non-blocking I/O and
> 
> Definitely.
> 
> > kludges like splitting the data into several system calls.
> 
> 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.

> 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? :-)  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