From: Dominik Werder <dwerder@...>
Date: 2003-05-16T19:53:39+09:00
Subject: Re: TCP Sockets

> Maybe, but threads are really the "ruby way" to solve this problem.
>
> In other words: if you care that the process blocks with a half-received
> HTTP request, because you want to be doing something else at the same 
> time,
> then the 'something else' can be done in another thread.
>
> Threads in Ruby are really just a convenient abstraction over select(). 
> If a
> thread is about to do an operation which would block, it adds its fd to
> those waiting for data, and hands over control to another thread. When 
> its
> fd becomes ready again, at a convenient time it will get control handed 
> back
> to it.

But what should I gonna do if I have to read binary data from one or more 
connections and want to line them up in packets to send them over a single 
connection to another host. In this case I can't wait for a newline or EOF 
cause the binary data may not contain CR/LF. Or if the sending server hangs 
the connection is established but theres no data flowing.. and so my 
connection hangs too (forever?)

I agree that threads are a clean solution in networking. But it seems to me 
that I have to able in some cases to know how much data I can read. Maybe 
I'm mistaken.

How do for example P2P clients do that? One thread per connection?

thanks!
Dominik