libuv和libev的区别

libuv 和 libev ，两个名字相当相近的 I/O Library，最近有幸用两个 Library 都写了一些东西，下面就来说一说我本人对两者共同与不同点的主观表述。

高性能网络编程这个话题已经被讨论烂了。异步，异步，还是异步。不管是 epoll 也好，kqueue 也罢，总是免不了异步这个话题。

• libev 是系统异步模型的简单封装，基本上来说，它解决了 epoll ，kqueuq 与 select 之间 API 不同的问题。保证使用 livev 的 API 编写出的程序可以在大多数 *nix 平台上运行。但是 libev 的缺点也是显而易见，由于基本只是封装了 Event Library，用起来有诸多不便。比如 accept(3) 连接以后需要手动 setnonblocking 。从 socket 读写时需要检测 EAGAIN 、EWOULDBLOCK 和 EINTER 。这也是大多数人认为异步程序难写的根本原因。

• libuv 则显得更为高层。libuv 是 joyent 给 Node 做的一套 I/O Library 。而这也导致了 libuv 最大的特点就是处处回调。基本上只要有可能阻塞的地方，libuv 都使用回调处理。这样做实际上大大减轻了程序员的工作量。因为当回调被 call 的时候，libuv 保证你有事可做，这样 EAGAIN 和 EWOULDBLOCK 之类的 handle 就不是程序员的工作了，libuv 会默默的帮你搞定。

• libev 在 socket 发生读写事件时，只告诉你，“XX socket 可以读/写了，自己看着办吧”。往往我们需要自己申请内存并调用 read(3) 或者 write(3) 来响应 I/O 事件。

libuv 则稍微复杂一些，我们分读/写两个部分来描述

• 当接口可读时，libuv 会调用你的 allocate callback 来申请内存并将读到的内容写入。当读取完毕后，libuv 会 call 你为这个 socket 设置的回调函数，在参数中带着这个 buffer 的信息。你只需要负责处理这个 buffer 并且free 掉就OK了。因为是从 buffer 中读取数据，在你的 callback 被调用时数据已经 ready 了，所以程序员也就不用考虑阻塞的问题了。

• 而对写的处理则更显巧妙。libuv 没有 write callback ，如果你想写东西，直接 generate 一个 write request 连着要写的 buffer 一起丢给 libuv ，libuv 会把你的 write request 加进相应 socket 的 write queue ，在 I/O 可写时按顺序写入。

• C 没有闭包，所以确定读写上下文是 libuv 的使用者需要面对的问题。否则程序面对汹涌而来的 buffer 也不能分得清哪个是哪个的数据。在这一点的处理上，libuv 跟 libev 一样，都是使用了一个 void *data 来解决问题。你可以用 data 这个 member 存储任何东西，这样当 buffer 来的时候，只需要简单的把 data cast 到你需要的类型就 OK 了。

• libev 没有异步 DNS 解析，这一点一直广为垢病。

• libuv 有异步的 DNS 解析，解析结果也是通过回调的方式通知程序。

• libev 完全是单线程的。

• libuv 需要多线程库支持，因为其在内部维护了一个线程池来 handle 诸如 getaddrinfo(3) 这样的无法异步的调用。

• libev 貌似是作者一个人在开发，版本管理使用的还是 CVS ，社区参与度明显不高。

• libuv 社区十分活跃，几乎每天都有人提出 Issue 并贡献代码。

• libev 不支持 IOCP ，如果需要在 Win 下运行的程序会很麻烦。

• libuv 支持 IOCP ，有相应脚本编译 Win 下的库。