JavaScript 异步 IO 在 EventMachine 和 NodeJS 的写法对比

luikore · 发布于 2013年05月17日 · 最后由 hlxwell 回复于 2013年05月23日 · 6280 次阅读

本帖已被设为精华帖！

这周四的 ruby tuesday 听完 nodejs 介绍获益良多. 也了解到了 nodejs 社区绞尽心思改进异步写法的努力, 还有就是原生 nodejs 开发者其实不喜欢写同步风格的代码 -__- . javascript 处理异常要很小心, 因为 catch 不像 ruby 那样能区分异常类型, 一抓就会吞掉全部异常所以要尽量缩小 try 块...

一些名词很容易搞混: 异步 (async) 基本和并发 (concurrent) 一个意思, 但和并行 (parallel) 完全是两回事. eventmachine 和 nodejs 都是通过多进程实现并行, 通过异步 IO 实现并发的. 顺序不等于同步(如果了解 Haskell 的 Monad 和 Arrow 就会有更多的理解), 并发不等于并行.

eventmachine

# 顺序读文件
EM.defer do
  File.read 'a'
  File.read 'b'
end

# 并发读文件
EM.defer do
  File.read 'a'
end
EM.defer do
  File.read 'b'
end

ruby 里文件 io 天生是顺序同步的
ruby 里允许混入同步操作的库或者函数, 只要 defer 了就不会 block 住
defer 是线程池实现的, 由于 GVL, defer 操作没有并行效果但有并发效果

异步网络 IO 就要用到 callback 了, 但有 Fiber 这个工具在, 可以用 Fiber.yield 实现依赖的顺序化

# 读 url1 成功后才读 url2
def read_urls url1, url2
  f = Fiber.current
  req = HttpRequest.new(url1).get
  req.callback { f.resume }
  req.errback { f.resume }
  Fiber.yield # 将控制权交给任务队列, 然后在 callback 完成后会回到这里继续执行
  return 'bad' if req.response_header.status != 200

  req = HttpRequest.new(url2).get
  req.callback { f.resume }
  req.errback { f.resume }
  Fiber.yield
  return 'bad' if req.response_header.status != 200
end

Fiber.new {
  read_urls url1, url2
}.resume

nodejs

太复杂没记住 ... 总的来说顺序 IO 有好多套方案... 我还记得的有几种:

事件中心方案, 和写 jquery / eventmachine 的默认写法相似
CPS 方案, 多加一个 continuation 参数
重编译+eval 方案 (老赵的 Wind) 看起来挺高端的, 但是问题也很多: 大量增加载入时间; js eval 的代码不像 ruby 那样可以指定文件和行号, 不容易 debug; 要通过伪变量指示操作是顺序还是并发; 代码写的和做的事情不是一回事...
next() 方案

并发读在 node 就是天生的了, 但是如果下一步操作依赖上几步的结果, 就和顺序读一个思路.

另外不管哪个框架, 数个文件并发读应该是比顺序读慢的... 并发读文件只是演示用... 最优的操作就是一个本地文件读和数个网络 IO 并发

13 个赞

共收到 35 条回复

chancedoor · #1 · 2013年05月17日

请问帖子中列表要怎么写?就是行首的点

luikore · #2 · 2013年05月17日

#1楼 @ChanceDoor

- a
- b
- c

chancedoor · #3 · 2013年05月17日

#2楼 @luikore

Thanks!

doitian · #4 · 2013年05月17日

还有 Promise/Future

bhuztez · #5 · 2013年05月17日

根本就不需要什么老赵那个坑爹的wind.js，JavaScript本来就能yield的啊，只是V8不支持罢了

luikore · #6 · 2013年05月17日

#5楼 @bhuztez 好吧, 可以用 js-coroutine

bhuztez · #7 · 2013年05月17日

#6楼 @luikore

https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Iterators_and_Generators#Generators.3A_a_better_way_to_build_Iterators

coroutine是可以，但是，作为浏览器回调函数感觉会很费解

krazy · #8 · 2013年05月17日 1 个赞

yield就快啦 http://wingolog.org/archives/2013/05/08/generators-in-v8 还有node-fibers

wind.js文档又少而且他自己都说不维护了 synchronous-to-asynchronous-javascript-compilers-cps

node-core本来是用的promise的，不过因为callback形式比较流行又换过去了现在是把promise的实现，控制流管理之类的都放到user-land 还有个fantasy-land,想把functor,monad之类的引进去

luikore · #9 · 2013年05月17日

不过感觉就是, 这么强调异步的话, 框架选 haskell 才对... 数据依赖不用手动管理世界都清净了, 还有个小小优点是单进程能解决并行问题.

bhuztez · #10 · 2013年05月17日

#9楼 @luikore Erlang啊...

luikore · #11 · 2013年05月17日

#10楼 @bhuztez 是的, 学习 erlang 的动力大增 XD

bhuztez · #12 · 2013年05月17日

#11楼 @luikore

There is no clear winner in the duel. I prefer Haskell, but I am biased and believe in static typing. Yet I like programming in Erlang - both languages are good from different perspectives.

http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlang-for-bittorent-clients.html

After 2 months of tuning on and off I went back to Erlang Unoptimized Erlang version as fast as Combinatorrent in practice

http://www.erlang-factory.com/upload/presentations/658/jlouis-euc-2012.pdf‎

luikore · #13 · 2013年05月17日

#12楼 @bhuztez 性能看情况吧, 我用 ruby 写的 parser combinator 比 haskell parsec 快...

luikore · #14 · 2013年05月17日

#12楼 @bhuztez 但 haskell 可以说是 multi-paradigm 的, do-notation 里可以写 state 什么的很舒服...

bhuztez · #15 · 2013年05月17日

#14楼 @luikore Erlang也可以do notation的...

https://github.com/rabbitmq/erlando

krazy · #16 · 2013年05月17日

#14楼 @luikore scala呢也有actor可以用哇

luikore · #17 · 2013年05月17日

#16楼 @krazy scala启动和编译太慢了函数签名就和C++ boost模板库一样变态, 还要各种用java的库(java库的 API 你懂的), 还要考虑线程安全(和库的线程安全)的问题, eventmachine/nodejs 单线程完全不用管, erlang/haskell 没有 mutable state 的问题也完全不用管

再说,任何内建XML语法的语言都应该被踩...