ucontext を使用するライブラリを、pthreads をサポートするが ucontext をサポートしないプラットフォームに移植しようとしています。コードはかなりよく書かれているので、ucontext API へのすべての呼び出しを pthread ルーチンへの呼び出しに置き換えるのは比較的簡単です。ただし、これにより、かなりの量の追加のオーバーヘッドが発生しますか? それとも、これは満足のいく代替品ですか。ucontext がオペレーティング システムのスレッドにどのようにマップされるかはわかりません。この機能の目的は、コルーチンのスポーンをかなり安価で簡単にすることです。
質問は、ucontext 呼び出しを pthread 呼び出しに置き換えると、ライブラリのパフォーマンス特性が大幅に変わるのでしょうか?
pthread は、システム コールと、わずかに管理メモリを使用します。同じ量のシステムコールが必要であると仮定すると、ucontext に匹敵するはずです (strace を使って単純に確認します)。
同じ理由で、swapcontext() は、いくつかの longjmp トリックを使用するよりも遅くなります (著者がアプリケーションのパフォーマンスに 7 倍の影響を与えると主張している議論については、このページを参照してください)。
私はこのテーマの専門家ではありませんが、コルーチン spice-gtk を使用してライブラリを開発しており、ucontext/jmp、gthread、または winfibers を使用したバックエンドがあります。私はパフォーマンスの変化に気づきませんでしたが、それはおそらく lib が一般的に IO バウンドであるためです。