如果说"密钥协商，和登录认证"造成了“IO长时间占用线程”的话，那应该说明的是，之前“接续模式”的程序本身的IO方式有些问题

因为SSL_do_handshake本身支持以非阻塞方式进行，主要是适当的处理SL_ERROR_WANT_READ和SSL_ERROR_WANT_WRITE；

登录认证就更不用说了，肯定只是一些应用层的消息交互，如果设计没问题，这必然不可能造成IO长时间占用线程

实际上，我理解中stackful的协程，内存占用天然的会比你所讲的接续模式或者stackless协程多，因为后二者只需要把必要的数据保留在控制块或者协程体中，而stackful本质上是把stack里的东西全部保留住直到下一次被调度（等待的事件到来），stack里面的东西必然有尚未弹出的非必要数据，这些非必要数据一起被保留在内存里，所以内存占用必然会多

【 在 ylh0315 的大作中提到: 】
: 说的非常对。
: 交易管理器的设计，原来是没有协程的。采用接续模式。就是把任务划分成一个个的部分（我管他叫珠子），由IO（epoll，链子）接续起来。这样也能解决80~90%的问题。
: 但是有两个问题：
: ...................
--
FROM 113.120.108.*