我正在阅读http://olk.github.io/libs/fiber/doc/html/在我看来，Boost.Fiber C++ 正在接近 Erlang 拥有数千个“进程”的能力，也称为“绿色”进程[线程]” http://en.wikipedia.org/wiki/Green_threads。
我的问题是，Boost.Fiber 准备好投入生产了吗，现在有没有更好的文档和示例的 c++ 替代品？有人提到轻量级线程，但我似乎无法找到它的参考。最后一个问题是，为什么 C++ 标准不包括 Fibers？
我对此感兴趣的原因是因为我有实时更新，其中值的变化可能会影响（产生）成百上千的小但令人尴尬的并行计算。C++ 线程模型不能很好地工作，imo。请不要使用 GPU，因为目前将信息传入和传出 GPU 需要很长时间。
我意识到 Erlang 远不止于此，所以请不要在一般情况下对我进行 Erlang 与 C++ 的教育。
Boost.Fiber 在 2014 年 1 月由 Boost 社区进行了审查，发现需要大量的额外工作。请参阅http://lists.boost.org/boost-announce/2014/01/0393.php上的社区审查结果。
C++ 17 还希望获得一个类似 WinRT 的 M:N 线程模型，该模型基于使用建议的 await 关键字的可恢复函数。微软已经在他们的编译器中实现了支持，除了未来的神奇内存分配技巧之外，它看起来非常有前途。相关的 N 论文是 N4134 ( http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4134.pdf )，如您所见，如果被接受，这种可恢复函数的表述即使语法有点迟钝，它确实会提供 Erlang 类型的可伸缩性（嘿，它是 C++，它的语法什么时候变得简单了！）。
当然，如果您现在需要一个可移植的解决方案，要么使用 ASIO 使用无堆栈协程路由（注意：它很脆弱），或者使用类实例作为您的执行状态，使用类实例作为执行状态的细粒度 ASIO 处理程序，或者否则无论如何都要使用 Boost.Fiber。如果您只需要 Windows，我会亲自推进微软的专有扩展，除非他们放弃 WinRT，否则他们极不可能放弃它们：)
编辑： Boost.Fiber 的作者告诉我，截至 2015 年 1 月，来自社区审查的建议更改已经完成，除了文档改进之外，Fiber 被认为已准备好包含在官方 Boost 中。如果确实如此，那么在编译器中出现对最终可恢复函数的官方 C++ 17 语言支持之前，Fiber 可能是最好的解决方案。