[#10193] String.ord — David Flanagan <david@...>

Hi,

41 messages 2007/02/05
[#10197] Re: String.ord — Yukihiro Matsumoto <matz@...> 2007/02/06

Hi,

[#10198] Re: String.ord — David Flanagan <david@...> 2007/02/06

Yukihiro Matsumoto wrote:

[#10199] Re: String.ord — Daniel Berger <djberg96@...> 2007/02/06

David Flanagan wrote:

[#10200] Re: String.ord — David Flanagan <david@...> 2007/02/06

Daniel Berger wrote:

[#10208] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10213] Re: String.ord — David Flanagan <david@...> 2007/02/06

Nikolai Weibull wrote:

[#10215] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10216] Re: String.ord — David Flanagan <david@...> 2007/02/07

Nikolai Weibull wrote:

[#10288] Socket library should support abstract unix sockets — <noreply@...>

Bugs item #8597, was opened at 2007-02-13 16:10

12 messages 2007/02/13

[#10321] File.basename fails on Windows root paths — <noreply@...>

Bugs item #8676, was opened at 2007-02-15 10:09

11 messages 2007/02/15

[#10323] Trouble with xmlrpc — James Edward Gray II <james@...>

Some of the Ruby code used by TextMate makes use of xmlrpc/

31 messages 2007/02/15
[#10324] Re: Trouble with xmlrpc — "Berger, Daniel" <Daniel.Berger@...> 2007/02/15

> -----Original Message-----

[#10326] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/15

On Feb 15, 2007, at 1:29 PM, Berger, Daniel wrote:

[#10342] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

While I am complaining about xmlrpc, we have another issue. It's

[#10343] Re: Trouble with xmlrpc — Alex Young <alex@...> 2007/02/16

James Edward Gray II wrote:

[#10344] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

On Feb 16, 2007, at 12:08 PM, Alex Young wrote:

Re: Stateful I/O interface

From: Paul Brannan <pbrannan@...>
Date: 2007-02-22 20:15:04 UTC
List: ruby-core #10395
On Tue, Feb 20, 2007 at 11:24:52AM +0900, Tony Arcieri wrote:
> 
>    Has anyone ever suggested adding a stateful I/O multiplexing
>    interface which could be used for things like network servers where
>    something like Kernel#select is less than ideal?

For now, I think this is best done as a library.  The reactor pattern is
a well-accepted pattern for implementing such a mechanism.  There is a
reactor library for ruby, but it needs to have additional I/O
multiplexing mechanisms implemented.

I would like to see a way to pick a different I/O multiplexing mechanism
at runtime.  IMO the problem isn't what Kernel#select does (you don't
have to use it), but what rb_thread_select does (you aren't given a
choice here).  Integrating ruby's event loop with a library that uses a
different mechanism requires that the library be able to use ruby's I/O
multiplexing system, but may not be possible or desirable, especially if
ruby is embedded in an application.

It's been suggested that Ruby use WaitForMultipleObjects on win32 (see
[ruby-talk:47186]).  There are pros and cons to doing this, but I'm not
qualified to enumerate them.

Paul


In This Thread