"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