How does libuv compare to Boost/ASIO? [closed] Ask Question

_{1.スキャッター/ギャザーI/O。}

_{2. Boost.Extension はBoost にレビューのために提出されたことはありません。ここで述べたように、作者はそれが完成していると考えています。}

イベントループ

libuv と Boost.Asio はどちらもイベント ループを提供しますが、両者の間には微妙な違いがいくつかあります。

• uv_default_loop()libuv は複数のイベント ループをサポートしていますが、複数のスレッドから同じループを実行することはサポートしていません。このため、別のコンポーネントがデフォルト ループを実行している可能性があるため、新しいループ ( ) を作成するのではなく、デフォルト ループ ( )を使用する場合は注意がuv_loop_new()必要です。
• Boost.Asio にはデフォルトのループという概念はありません。すべてはio_service複数のスレッドを実行できる独自のループです。これをサポートするために、Boost.Asio はパフォーマンスを犠牲にして内部ロックを実行します。Boost.Asio の改訂履歴を見ると、ロックを最小限に抑えるためにパフォーマンスが何度か改善されたことがわかります。

スレッドプール

• libuv は を通じてスレッドプールを提供しますuv_queue_work。スレッドプールのサイズは環境変数 で設定できますUV_THREADPOOL_SIZE。作業はイベント ループの外側、スレッドプール内で実行されます。作業が完了すると、完了ハンドラがキューに入れられ、イベント ループ内で実行されます。
• Boost.Asio はスレッドプールを提供しませんが、複数のスレッドが を呼び出すことができるio_serviceため、 は簡単にスレッドプールとして機能することができます。この例でわかるように、これにより、スレッドの管理と動作の責任がユーザーに移ります。io_servicerun

スレッドと同期

• libuv はスレッドと同期タイプの抽象化を提供します。
• Boost.Thread は、スレッドと同期型を提供します。これらの型の多くは C++11 標準に厳密に従っていますが、いくつかの拡張機能も提供しています。Boost.Asio では、複数のスレッドが単一のイベント ループを実行できるため、明示的なロック メカニズムを使用せずにイベント ハンドラーを順番に呼び出す手段としてストランドが提供されます。

ファイルシステム操作

• libuv は、多くのファイル システム操作の抽象化を提供します。操作ごとに 1 つの関数があり、各操作は同期ブロッキングまたは非同期のいずれかになります。コールバックが提供されている場合、操作は内部スレッドプール内で非同期に実行されます。コールバックが提供されていない場合、呼び出しは同期ブロッキングになります。
• Boost.Filesystem は、多くのファイル システム操作に対して同期ブロッキング呼び出しを提供します。これらを Boost.Asio およびスレッドプールと組み合わせて、非同期ファイル システム操作を作成できます。

ネットワーキング

• libuv は、UDP および TCP ソケットでの非同期操作、および DNS 解決をサポートします。アプリケーション開発者は、基礎となるファイル記述子が非ブロッキングに設定されていることに注意する必要があります。したがって、ネイティブの同期操作では、またはの戻り値とerrno をチェックする必要があります。EAGAINEWOULDBLOCK
• Boost.Asio は、ネットワーク サポートが少し充実しています。libuv のネットワークが提供する多くの機能に加えて、Boost.Asio は SSL および ICMP ソケットをサポートしています。さらに、Boost.Asio は、非同期操作に加えて、同期ブロッキング操作と同期非ブロッキング操作を提供します。設定されたバイト数を読み取る、または指定された区切り文字が読み取られるまで読み取るなど、一般的な高レベル操作を提供する多数の独立した関数があります。

信号

• libuv は、その型と操作killによる抽象化とシグナル処理を提供します。uv_signal_tuv_signal_*
• Boost.Asio は の抽象化を提供しませんkillが、signal_setシグナル処理を提供します。

国際PC

• libuv は、Unix ドメイン ソケットとWindows 名前付きパイプを単一のuv_pipe_t型で抽象化します。
• Boost.Asio はこれら 2 つをlocal::stream_protocol::socketまたはlocal::datagram_protocol::socketとに分離しますwindows::stream_handle。

APIの違い

API は言語によってのみ異なりますが、主な違いは次のとおりです。

オペレーションとハンドラーの協会

Boost.Asio では、操作とハンドラーの間に 1 対 1 のマッピングがあります。たとえば、各操作はWriteHandlerasync_writeを 1 回呼び出します。これは、多くの libuv 操作とハンドラーに当てはまります。ただし、libuv は多対 1 のマッピングをサポートしています。複数の呼び出しにより、 uv_async_cb が1 回呼び出される場合があります。uv_async_senduv_async_send

コールチェーンとウォッチャーループ

ストリーム/UDP からの読み取り、シグナルの処理、タイマーの待機などのタスクを処理する場合、Boost.Asio の非同期呼び出しチェーンはもう少し明確になります。libuv では、特定のイベントへの関心を指定するためにウォッチャーが作成されます。次に、ウォッチャーのループが開始され、コールバックが提供されます。関心のあるイベントを受信すると、コールバックが呼び出されます。一方、Boost.Asio では、アプリケーションがイベントの処理に関心を持つたびに、操作を発行する必要があります。

async_receiveこの違いを説明するために、呼び出しが複数回発行されるBoost.Asio を使用した非同期読み取りループを次に示します。

void start()
{
  socket.async_receive( buffer, handle_read ); ----.
}                                                  |
    .----------------------------------------------'
    |      .---------------------------------------.
    V      V                                       |
void handle_read( ... )                            |
{                                                  |
  std::cout << "got data" << std::endl;            |
  socket.async_receive( buffer, handle_read );   --'
}    

uv_read_start( socket, alloc_buffer, handle_read ); --.
                                                      |
    .-------------------------------------------------'
    |
    V
void handle_read( ... )
{
  fprintf( stdout, "got data\n" );
}