【问题标题】:Please explain the logic behind this ruby fiber example请解释这个 ruby​​ Fiber 示例背后的逻辑
【发布时间】:2012-09-21 16:04:03
【问题描述】:

示例代码来自here:

def http_get(url)
  f = Fiber.current
  http = EventMachine::HttpRequest.new(url).get

  # resume fiber once http call is done
  http.callback { f.resume(http) }
  http.errback  { f.resume(http) }

  return Fiber.yield
end

EventMachine.run do
  Fiber.new{
    page = http_get('http://www.google.com/')
    puts "Fetched page: #{page.response_header.status}"

    if page
      page = http_get('http://www.google.com/search?q=eventmachine')
      puts "Fetched page 2: #{page.response_header.status}"
    end
  }.resume
end

因此,在 EM 运行块的上下文中,作者创建了一个纤程并立即使用 resume 运行它。但是,我不明白为什么http_get 逻辑是以这种方式构造的。我的意思是,它使用当前的纤程(在这种情况下应该是在 EM 运行块中创建的纤程),它启动一个可能失败或成功的 http 请求,然后恢复当前的纤程。之后它只是在光纤上调用yield。自从他打电话给yield之后,究竟会发生什么?有人能解释一下为什么http_get 是这样写的吗?

【问题讨论】:

    标签: ruby eventmachine fiber


    【解决方案1】:
    1. Fiber 在 EventMachine 中创建和触发
    2. 目标是 (a) 获取页面并 (b) 处理该页面
    3. Fiber应该暂停直到页面被抓取,这就是http_get的作用
    4. http = EventMachine::HttpRequest.new(url).get 不会触发任何事情:EventMachine 需要重新控制,这就是 Fiber.yield 的作用
    5. 一旦 EventMachine 完成获取页面的工作,它就会触发回调并恢复在 puts ... 停止的 Fiber

    更清楚吗?

    【讨论】:

    • 为什么要暂停光纤?此外,代码在 puts "Fetched page: #{page.response_header.status}" 处停止,直到光纤有机会运行和完成?
    • 将手传递给 EventMachine
    • 谢谢,现在很清楚了。既然你有一些 EM 经验,你可以快速浏览一下stackoverflow.com/questions/12663944/… 吗?也许你能发现我做错了什么?
    • 是否存在竞争条件?例如是否可以在 yield 之前调用 resume?
    猜你喜欢
    • 2021-10-17
    • 1970-01-01
    • 2017-05-25
    • 2021-12-05
    • 1970-01-01
    • 1970-01-01
    • 2012-08-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多