在现实世界中，基本是是按着这样的顺序演化：process–>thread–>coroutine/fiber

其实是一个context切换开销从大到小的演化，process切换开销最大，需要切换地址空间，所有的CPU状态，所有其他资源

thread切换只需要切换CPU状态，当然是大部分的CPU状态，而coroutine切换，只需要切换很少的CPU状态，而且全部都在用户地址空间运行，不需要到内核空间。

当然，切换coroutine的开销还是比一次函数调用大很多，其实函数调用也是一个cpu状态的切换，不过这个状态要少得多，在x86 windows 上，甚至不必保存所有的寄存器状态（EAX/ECX/EDX在函数调用之间就不用保证，EAX保存返回值），有些调用甚至通过寄存器传递参数……比起coroutine，太微不足道了。

coroutine其实也可以看成是一个保留了以前调用状态（另一个堆栈帧）的函数调用，在寄存器很多的系统上（如Itanium），切换寄存器状态的开销还是比较大的，如果哪一天大家又开始嫌coroutine也太慢，那怎么办？

boost::shared_ptr 对象中，有两个成员一个是对象 ptr，一个是引用计数类的指针，由于某种原因，我希望把 shared_ptr 放入一个指针大小的地方，却无法实现，只能用 intrusive_ptr，但是牵涉到的类又太多，改起来不现实，仔细想一下，其实 shared_ptr 完全可以只有一个指针大小，只要把对象指针放到引用计数类中就可以了，为什么shared_ptr作者不这么干？是他没想到？我觉得不太可能。或者只是为了减少一次内存访问？我觉得也不太可能。这到底有什么更深层次的原因？

  前段时间自作聪明的还以为自己发现了一个完美的解决异步IO的方法，还真太把自己当回事了。人家已经早有这个办法了，还有个学名，叫做Coroutine，在异步IO中的应用也已经非常多了，我真是太孤陋寡闻了。

刚才看coroutine，在这个页面

感觉最有意思的是这一段话：

(The header file is MIT-licensed, so you can use it in anything you like without restriction. If you do find something the MIT licence doesn’t permit you to do, mail me, and I’ll probably give you explicit permission to do it anyway.)