看76楼，应用调用了接收函数，是个通用函数，单任务，多进程，多线程，线程池模式都是调用这个函数，应用程序（插件）根本就不知道任何的模式。
在前三个模式下，当调用这个函数时，的确陷入更待，直到银行回复，或超时，没啥问题。
但是在线程池模式下，几个这样的任务就把线程耗尽。
会要求应用软件按照异步模式修改代码吗？考虑过，有点难。
于是，有了协程，在那个函数内部，判断是协程环境，就以NONBLOCK方式接收消息，没有消息就yield。把协程的context排入epoll（事件管理器），释放线程。等银行那边有消息了，epoll会把这个context激活，交给一个线程，线程会resume回来，继续未完的接收。直到任务完成，接收函数正常返回，该函数的使用，没有任何变化，基本不需要修改用户程序。
这个过程说明，异步过程，进行两次协程切换和一组epoll的排队和激活过程，开销比同步过程大太多了，还没说其中还要写好些日志。
因此说协程是为了减小切换开销是不对的，我这里凭空增加了大量开销。
【 在 finlab 的大作中提到: 】
: 协程很多场合是为了节省线程切换的成本，提高cpu的利用率。
: 但是经常把一个事情劈成两半，绕了半天还是要再捏到一起。
: 既然协程这么流行，那就不如在cpu和操作系统、编译器层面进行优化，
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*