From: Tony Arcieri <tony@...>
Date: 2008-02-16T09:28:56+09:00
Subject: Re: eventmachine and rev

------=_Part_2965_6635313.1203121741465
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, Feb 15, 2008 at 5:13 PM, James Gray <james@grayproductions.net>
wrote:

> Is that true?  I thought they were added to the 1.8 branch too.
>

Interesting.  I wasn't aware of that, but you appear to be correct.  That
would make adding 1.8 support to Rev a lot easier.

Well, in addition to the *_nonblock methods, the Rev C extension is using
the rb_thread_blocking_region() function to perform blocking system calls.
In order to work on 1.8 this would need to be removed and replaced with a
workaround that blocks only for short intervals then allows the Ruby
scheduler to run.

There's some other bits which are 1.9 specific which would require
workarounds as well.  For example, #instance_exec is used to implement the
ability to define callbacks at runtime, e.g.:

  HOST = '127.0.0.1'
  PORT = 4321

  server = Rev::TCPServer.new(ADDR, PORT) do |c|
    c.on_connect { puts "#{remote_addr}:#{remote_port} connected" }
    c.on_close   { puts "#{remote_addr}:#{remote_port} disconnected" }
    c.on_read    { |data| write data }
  end

  server.attach(Rev::Loop.default)

  puts "Echo server listening on #{HOST}:#{PORT}"
  Rev::Loop.default.run

The on_connect, on_close, and on_read callbacks all use instance_exec to
allow them to execute in the scope of the watcher object (giving access to
remote_addr, remote_port, write, etc.)

Obviously #instance_eval would suffice for on_connect / on_close, but
on_read takes a parameter, as do several other callbacks in the API.

-- 
Tony Arcieri
ClickCaster, Inc.
tony@clickcaster.com

------=_Part_2965_6635313.1203121741465--