缘起
我真的觉得这个库完成度很高，功能完善，文档详细，而且是中国的公司（爱奇艺）维护的，可预见的时间内都会是活跃的项目，还经过了生产环境的检验。总之种种原因，让我觉得这个项目还不错。看了代码后我更心动了。
为什么要用协程
协程除了可以提供更高并发的支持，还可以使用同步的方式写异步执行的代码，使得代码逻辑更加简洁和清晰。
协程的栈
目前我看到的示例代码里，libfiber的协程都是使用独立的栈，也就是属于stackfull类型的协程。这点和腾讯的协程库libco默认模式是一样的。
对应的还有一种stackless的协程，也就是共享栈的模式，这种模式下同样物理内存可支持更多的协程（所以支持更高的并发），但是切换效率低一些。libco据说也支持的，我没试过。
一般为一个程协提供128K的栈空间，可以自己调大或调小。对libfiber来说，在128K模式下，1GB内存支持8192个协程，对于普通的业务，足够了。
调度模型
首先，libfiber的协程不能跨线程调度，这点和golang不太一样。但是这样的处理方式也更简单，我个人不认为这是多大的缺点。况且libfiber实现了线程和协程的同步方式，“多线程+多协程”也不在话下。
其次，libfiber的协程切换不需要返回上一层，也就是说libfiber的协程是“对称”的，没有一个中心化的调度协程，这样调度起来效率更高。
libfiber的性能
下图给出了采用 libfiber 编写的回显服务器与采用其它网络协程库编写的回显服务器的性能对比（对比单核条件下的 IO 处理能力）：
看起来不错！
同步、通信方式
channel
相当于一个管道，最大容量100（可以自己修改代码修改这个固定容量）。
应该只能用于同一线程里的协程间通信。
fiber_mutex
仅能用于同一线程内部的协程之间进行互斥的互斥锁
fiber_event
可用于协程之间、线程之间以及协程与线程之间,通过事件等待/通知方式进行同步的事件混合锁
fiber_cond
基于fiber_event，可用在协程之间，线程之间，协程与线程之间的条件变量
fiber_sem和fiber_sbox
fiber_sem是一个协程间的信号量。fiber_sbox是基于fiber_sem的一个消息管道。
感觉其作用类似于channel,但是未限制容量。
fiber_tbox
用于协程之间，线程之间以及协程与线程之间的消息通信，通过协程条件变量及协程事件锁实现。
前面的channel和fiber_sbox都是用于同一线程里的协程间通信，这里可以跨线程。
