我正在研究一种类似 c++ 的小型语言，我将编译到 LLVM。我想要实现的一件事是协作式多任务处理；将会有一个“yield”操作符，它有望将堆栈指针和程序计数器切换到我程序中的下一个“线程”。

可以在llvm中做到这一点吗？我可以设置堆栈指针寄存器吗？如果没有，我还能做其他类似的事情吗？

编辑：LLVM 协程（http://llvm.org/docs/Coroutines.html）听起来很有希望，尽管https://internals.rust-lang.org/t/llvm-coroutines-to-bring-awarness/3708/12提出了一些关于堆栈或无堆栈协程的问题。我想知道，它们可以用来实现一个通用的类似产量的运算符吗？

编辑 2：在 c++ 中，boost 有一个叫做“上下文”的东西，它可以实现堆栈协程。仍然试图弄清楚他们是如何做到的。有人知道吗？

有没有办法将 boost context make_fcontext/jump_fcontext 与共享堆栈一起使用，通过保存/恢复堆栈来共享协程内存？

似乎make_fcontext和jump_fcontext自己写在堆栈上，当我尝试在 yield/resume 上保存/恢复堆栈时会崩溃，但我真的很难理解由于 make_fcontext/jump_fcontext 是纯汇编代码会发生什么。

这是触发分段错误的协程方法（如果我为每个协程使用不同的堆栈并且我不使用 saveStack/restoreStack，则相同的代码效果很好）

任何想法 ？我在某处做错了什么吗？

我正在阅读 boost fcontext 的实现。

make_fcontext 的函数原型是 typedef void* fcontext_t; fcontext_t BOOST_CONTEXT_CALLDECL make_fcontext( void * sp, std::size_t size, void (* fn)( intptr_t) );

第一个参数是上下文堆栈的顶部，来自 boost 文档的示例如下：

当我在 i386_elf 中阅读 make_context 的实现时，该实现总是减少 sp，它会使上下文存储在 sp 之前的内存中，这是 malloc 内存不足的。它可以覆盖不属于协程的内存吗？

我正在使用 boost context 1.67 在 Windows 10 上创建一个具有尽可能小的堆栈大小的光纤（fcontext API）。

可能这个问题不仅特定于提升上下文，而且适用于我们使用具有最小堆栈大小的 Windows 线程的任何场景。

我在使用非常小的堆栈（低于 10kb）时遇到了问题，这些堆栈溢出异常是由 boost 上下文引发的内部堆栈展开异常引起的，如下所示：

当使用更大的堆栈（> 10 kb）时，我没有遇到任何问题。

对于复制，以下示例就足够了：

Boost context 在这里仅用于执行与用户分配的堆栈的上下文切换，可能是由于 MSVC C++ 异常的一些限制引起的，这可能需要一定的最小堆栈大小才能工作。此外，SetThreadStackGuaranteeWinAPI 函数对该问题没有任何影响。

如示例所示，堆栈是通过 malloc 分配的。

使用 C++ 异常时，是否可以在 Windows 上使用小于 10kb 的堆栈？哪种情况可能导致这里的限制？

我正在做一些嵌入式项目，我想在 ARM cortex-M 中使用协程。不幸的是，Boost.coroutine2（内部使用了 Boost.context）并没有正式支持它。有什么方法可以调整 Boost 库以便能够使用 Boost.context 在 ARM cortex-M 中工作？

我正在使用boost::context::execution_context（版本 2）编写一个 C++ 11 库，我想将异常从一个传播execution_context到调用执行。

我想处理客户端提供给我的库函数的 lambda 内的异常；但是，我遇到了一个奇怪的问题，在某些情况下 boost::context 没有正确处理异常。

这可以按预期工作，并且与一些 boost 的测试和示例非常相似：

输出：

但以下更改不起作用：

我们添加一个包装类execution_context：

现在我们进行与之前相同的测试，但使用定义的类：

输出：

我注意到的唯一区别是它execution_context包含在一个类中，这会导致异常处理不当。这是没有意义的。

环境

我正在使用 GTest。

编译器

系统

促进

boost version 1.69.0 compiled for amd64

我正在使用make_fcontextand jump_fcontextfrom boost context 来实现用户空间上下文切换。我使用另一个库来捕获和报告应用程序崩溃。我发现这两个在 Windows 上不能一起工作。

崩溃库SetUnhandledExceptionFilter在启动期间调用以设置异常处理程序以从进程中捕获未处理的异常。然后它处理异常记录以进行崩溃报告。这在大多数情况下都有效，并且我的应用程序中没有其他异常处理。

但是，当在 boost 上下文上运行的线程中发生崩溃（硬件/软件异常）时，我发现设置的异常处理程序没有被触发。似乎相反，启动的内核WerFault.exe会在C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps.

似乎在 boost 上下文上运行会影响内核查找或使用被取代的全局未处理异常过滤器的能力。在 boost 上下文中运行时，堆栈的底部如下所示：

在普通 Windows 堆栈上运行时：

我想知道这里可能出了什么问题。我是 Windows 和 SEH 的新手，所以如果这个问题没有意义，请提前道歉。