我正在尝试将使用ucontext的库移植到支持pthread但不支持ucontext的平台上。代码编写得非常好，因此通过调用pthread例程来替换对ucontext API的所有调用应该相对容易。但是，这是否会引入大量额外开销？或者这是一个令人满意的替代品我不确定ucontext如何映射到操作系统线程，这个工具的目的是使协同生成相当便宜和容易。
所以，问题是：用pthread调用替换ucontext调用是否会显着改变库的性能特征？
答案 0 :(得分：0)
pthread将使用系统调用，并略微使用一些管理内存。它应该与ucontext相当，假设需要相同数量的系统调用（我会天真地用strace检查）。
出于同样的原因，swapcontext（）比使用一些longjmp技巧要慢（请参阅this page进行讨论，其中作者声称其应用程序的性能影响为7倍）。
我不是这方面的专家，但我使用coroutines spice-gtk开发了一个库，我们使用ucontext / jmp，gthread或winfibers进行后端处理。我没有注意到任何性能的变化，但这可能是因为lib通常是IO绑定的。