2

嗨，我一直在阅读关于 Thin 的文档，我对 eventmachine 相当陌生，但我知道 Deferables 是如何工作的。我的目标是了解当身体被延迟和部分流式传输时 Thin 是如何工作的。

以下是我正在使用并试图了解的示例。


class DeferrableBody
  include EventMachine::Deferrable

  def call(body)
    body.each do |chunk|
      @body_callback.call(chunk)
    end

   # @body_callback.call()
  end

  def each &blk
    @body_callback = blk
  end

end

class AsyncApp

  # This is a template async response. N.B. Can't use string for body on 1.9
  AsyncResponse = [-1, {}, []].freeze
  puts "Aysnc testing #{AsyncResponse.inspect}"

  def call(env)

    body = DeferrableBody.new    

    # Get the headers out there asap, let the client know we're alive...
    EventMachine::next_tick do
       puts "Next tick running....."
       env['async.callback'].call [200, {'Content-Type' => 'text/plain'}, body] 
     end

    # Semi-emulate a long db request, instead of a timer, in reality we'd be 
    # waiting for the response data. Whilst this happens, other connections 
    # can be serviced.
    # This could be any callback based thing though, a deferrable waiting on 
    # IO data, a db request, an http request, an smtp send, whatever.
    EventMachine::add_timer(2) do
      puts "Timer started.."
      body.call ["Woah, async!\n"]

      EventMachine::add_timer(5) {
        # This could actually happen any time, you could spawn off to new 
        # threads, pause as a good looking lady walks by, whatever.
        # Just shows off how we can defer chunks of data in the body, you can
        # even call this many times.
        body.call ["Cheers then!"]
        puts "Succeed Called."
        body.succeed
      }
    end

    # throw :async # Still works for supporting non-async frameworks...
    puts "Async REsponse sent."
    AsyncResponse # May end up in Rack :-)
  end

end

# The additions to env for async.connection and async.callback absolutely 
# destroy the speed of the request if Lint is doing it's checks on env.
# It is also important to note that an async response will not pass through 
# any further middleware, as the async response notification has been passed 
# right up to the webserver, and the callback goes directly there too.
# Middleware could possibly catch :async, and also provide a different 
# async.connection and async.callback.

# use Rack::Lint
run AsyncApp.new

我不清楚的部分是在call方法中的 DeferrableBody 类中发生了什么each。

我知道一旦计时器作为存储在@body_callback 中的块触发，并且当在主体上调用success 时，它会发送主体，但是当在这些块上被调用yield或被 call调用时，它如何在发送时变成单个消息。

我觉得我对闭包的理解不足以理解正在发生的事情。将不胜感激任何帮助。

谢谢你。

4

1 回答 1

2

好的，我想我弄清楚了每个块是如何工作的。

当连接进来的时候， thin onpost_init似乎正在生成一个@requestand@response对象。响应对象需要响应一个each方法。这是我们重写的方法。

这env['async.callback']是一个分配给类方法中调用的方法的闭包，post_process其中connection.rb数据实际发送到连接，如下所示


      @response.each do |chunk|        
        trace { chunk }
        puts "-- [THIN] sending data #{chunk} ---"
        send_data chunk
      end

响应对象的 each 是如何定义的


 def each
      yield head

      if @body.is_a?(String)
        yield @body
      else

        @body.each { |chunk| yield chunk }
      end
    end

所以我们的 env['async.callback'] 基本上是一个post_process在 connection.rb 类中定义的方法，通过method(:post_process)允许我们的方法像闭包一样被处理，其中包含对 @response 对象的访问。当反应器启动时，它首先将头部数据发送到next_tick它产生头部的地方，但此时主体是空的，所以什么都没有产生。

在此之后，我们的each方法将覆盖@response对象拥有的旧实现，因此当触发的add_timers火将post_process我们使用 提供的数据发送body.call(["Wooah..."])到浏览器（或任何地方）

完全敬畏 macournoyer 和致力于瘦身的团队。如果您觉得这不是它的工作方式，请纠正我的理解。

于 2012-06-28T16:26:29.573 回答