On Apr 29, 2006, at 4:39 AM, Vlad GALU wrote:

>    I'd like to use Ruby for a quite high performance networking tool.
> In practice, writing a multithreaded C/C++ program is not pheasible
> due to the large connection pool I plan to manage, which would impose
> a very scarce stack size. From what I can see, Ruby's default I/O
> semantics are synchronous. One can opt for using IO#select though.
> Let's just say synchronous is OK, API-wise. My question is: if I use
> one (Ruby) thread per client, would it block the whole Ruby
> interpreter while performing blocking I/O ? On my system (FreeBSD)
> ruby is linked against libpthread, for a good reason I guess. Could it
> be that it splits blocking routines to a separate (POSIX) thread ? If
> not, I'll probably end up replacing the select() implementation with
> kqueue() calls in the Ruby code.
>
> --
> If it's there, and you can see it, it's real.
> If it's not there, and you can see it, it's virtual.
> If it's there, and you can't see it, it's transparent.
> If it's not there, and you can't see it, you erased it.
>
I'd just like to point at another option, IO::Reactor
http://www.deveiate.org/projects/IO-Reactor/