就需要个协程。

我把这个思维方式应用在我们一些服务端业务逻辑开发上。比如我手头有个 OLAP 的小型数据库。有了协程以后，我整个程序结构很简单，每个数据集开个线程，相互独立。每个数据集都有很多请求，每个请求过来是一个协程。

               thread1 (workset1)
process -->    thread2 (workset2)
               thread3 (workset3)   --->  fiber1 (request)
                                    --->  fiber2 (request)

数据集我弄了个 shared_ptr<WorkingSet>，每个用于处理协程的请求都保持它的一份引用。更新数据集时，是替换这个 shared_ptr<> 而不是直接更新它——当然，我这个技术是适配我这种多读少写的情况。如果是多读多写，那得用 rust 的 btree map 那种支持 cow 的数据结构才对。但思路都一样。

上面几个 thread 虽然相互是独立的，但我用了线程间 RPC blocking queue，类似于 golang 的 chan，修改另外一个 workset 时，不需要搞序列化与反序列化，非常快。

每个请求一个协程，当这个请求结束时，各种资源跟着这个协程的销毁一起销毁了。我没感觉到管理资源有啥难度。

【 在 milksea 的大作中提到: 】
: 你这个思路需要什么语言机制么？看着像底层库开发
--
修改:hgoldfish FROM 110.84.123.*
FROM 110.84.123.*