From: Robert Klemme <shortcutter@...>
Date: 2006-04-29T17:55:34+09:00
Subject: Re: Multiplexed I/O

2006/4/29, Vlad GALU <vladgalu@gmail.com>:
>     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 ?

No. You can have a multi threaded application that uses blocking IO
(interface wise) concurrently.  Bute even though Ruby's threads are
non native there is a certain overhead associated with them. Using
select together with a thread pool might be an option, too. This
approach usually scales better than individual threads per IO.

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

Not as far as I know.

> If
> not, I'll probably end up replacing the select() implementation with
> kqueue() calls in the Ruby code.

If I was going to write a high performance application that had to
deal with a lot concurrent IO channels I'd choose Java's NIO. You get
select like behavior plus fairly easy MT handling - if you need that -
and also an easier programming model than C/C++ which is nevertheless
as performant.

Kind regards

robert

--
Have a look: http://www.flickr.com/photos/fussel-foto/