你愿意怎么办就怎么办吧。
反正，我给你看了那个动态模块热插拔管理。
不需要模块内部关心什么线程协程。
管理也是非常简单，被管理者与管理者没有什么耦合。
而且在大多数时间没有锁，只有一个引用计数管着。
线程与模块也是无关的，此时在某模块，彼时在另一模块。
模块的变更与线程无关。只看引用计数。

用C的线程，管理C++的模块。写模块的，不用管环境，专注你的业务。
【 在 z16166 的大作中提到: 】
: 在类中开线程，可以给线程lambda传递this指针，比较方便访问类的private member
: 解决办法是有的，除了上面说的用小锁，
: 另一个办法是拿着锁，move到临时变量里，放掉锁，再join线程
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

粒度是so。
为了简便管理，要求每个模块一个so一个入口，完成一个单一功能。

如果需要许多模块协同工作，一般情况就在客户端处理，把问题分成很多步骤，串行或并行的各个部分，按次序发给服务器，然后再合并处理，就是所谓的map-reduce方法。
服务器框架处理线程协程连接池负载均衡容错交易完整性等等乱七八糟的，挺费神的问题。
业务人员就是一方面写客户端完成流程，另一方面写模块完成具体操作。他们只需要了解各层的借口规范，了解线程安全协程安全的要求即可。
【 在 z16166 的大作中提到: 】
: 您那个动态加载没啥问题，是常见手法，要看锁的粒度是到dll/so，还是到dll/so导出的每个接口。
: 有个userspace RCU，借鉴的linux kernel的搞法，专门解决read-copy-update场景的需求，貌似也可以用来更新这个dll/so导出的接口指针表。
:
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*