問題タブ [libuv]

このチュートリアルに従って、Fedora 20 に vNext をインストールしようとしました。次のメッセージが表示されます。

問題は間違ったlibuvライブラリにあると思います。手伝って頂けますか？

イベント ループが 1 つのプロセス (つまり、1 つのコア) で実行されることは理解していますが、そこからスレッドを起動するとどうなるか知りたいです。

uv_thread_createまたはで複数のスレッドを起動するuv_queue_workと、それらは複数のコアで実行されますか (利用可能な場合)?

（少なくともUnixでは）すべてが複数のコアにスケーリングできるpthreadsに基づいているため、そうしてくれることを願っていますが、わかりません。

また、私はモバイルにいるため、現在それを確認するためのコードを書くことができません。すでに答えを知っている人がいるかどうかを確認するために投稿しました。

ハッピーホリデー。

編集: テスト コードを作成し、すべてが単一のコアで実行されます。

nodejs の request モジュールを使用して毎秒数百のリクエストを実行すると、次のエラーが発生することがあります

どうすれば信号をキャッチできますか?

C++ プログラムで libuv を使用しています。C を継承する A と B の 2 つのクラスがあります。

libuv を使用し、uv_signal_tC で のインスタンスを宣言しました。 のインスタンスを作成するにuv_signal_tは、コールバックを渡す必要があります。静的メンバー関数への参照の問題を回避するために、ラムダを C 関数に簡単に渡すことができます。

しかし、子クラスごとに異なるコールバックの実装を提供するにはどうすればよいでしょうか? 理想的には、C.cpp にいくつかの共通コードを実装し、各子に追加のコードを実装します。

アップデート

明確にするために、libuv で定義されているため、コールバック メソッドのシグネチャを変更することはできません。libuv のソースを編集することはできますが、そこまで深く掘り下げたいかどうかはわかりません。

私は Node.js の C コードを書いており、同期呼び出しと非同期呼び出しを区別したいと考えています。つまり、コードがメイン イベント ループ内から呼び出された V8 イベント ディスパッチ スレッドで実行されているのか、別のワーカー スレッドから呼び出されているのかを検出したいと考えています。前者の場合はすぐに JavaScript にコールバックできましたが、後者の場合はより複雑な非同期コールバックを使用する必要がありました。

libuv スレッド化 APIはuv_thread_self、現在のスレッドを識別し、uv_thread_equalスレッドが等しいかどうかを比較するために提供します。必要なのはuv_thread_t、メイン イベント ループの を見つけることだけです。

私は広範囲にネットワークと対話するアプリケーションにlibuvを使用しており、割り当てられたメモリを再利用するどの手法が同時に効率的であり、実行の libuv コールバック遅延で安全であるかを懸念しています。

libuv ユーザーに公開される非常に基本的なレイヤーでは、ハンドル リーダーの設定と共にバッファー割り当てコールバックを指定する必要があります。

どこuv_alloc_cbですか

しかし、ここに問題があります: このメモリ割り当てコールバックは、新しいメッセージがハンドルを介して受信されるたびに呼び出され (たとえば、ハンドルからの各 UDP データグラムuv_udp_tが受信されます)、各受信 UDP データグラムに対する新しいバッファの単純な割り当ては非常に非メモリのようです。 -賢い。

したがって、可能な場合は同じ割り当てられたメモリを再利用する一般的な C 手法 (おそらく、libuv コールバック システムによって導入された遅延実行コンテキスト内) を求めています。

また、可能であれば、windows-portable のままにしたいと考えています。

ノート：

• 私はこの質問を認識しています: libuv はバッファを接続にアタッチして再利用する機能を提供しますか? 受け入れられた答えは、静的に割り当てられたバッファがうまくいかないという事実を述べる以外に、libuvで実際にメモリ割り当てを正しく行う方法には答えません。特に、(ラッパー構造または handle-> のいずれかを介して) ハンドルにアタッチされたバッファーの安全性 (libuv メイン ループの複数の反復にわたる別の読み取りコールバック呼び出しとオーバーラップする可能性がある、同じバッファーでの遅延書き込みコールバック) をカバーしていません。データ コンテキスト)。

• http://nikhilm.github.io/uvbook/filesystem.htmlを読んで、スニップの下に次のフレーズがあることに気付きましたuvtee/main.c - Write to pipe:

  コピーを作成して、互いに独立して write_data への 2 つの呼び出しから 2 つのバッファーを解放できるようにします。このようなデモ プログラムでは問題ありませんが、主要なアプリケーションでの参照カウント バッファーやバッファーのプールなど、よりスマートなメモリ管理が必要になるでしょう。

  しかし、libuv バッファーでの参照カウントに関する解決策 (これを適切に実行するにはどうすればよいでしょうか?) や、libuv 環境でのバッファーのプールの明示的な例 (そのためのライブラリはありますか?) を見つけることができませんでした。

IP aaa.bbb.ccc.ddd のポート 1234 に UDP パケットを送信し、応答を待機する、python-twisted で記述されたクライアントがあります。また、ポート 1234 でリッスンし、クライアントに応答する C-libuv で記述された UDP サーバーもあります。

両方を同じマシンで実行すると、UDP サーバーのログから、データが受信され、応答が返されたことがわかります。しかし、クライアントのログには、受信した UDP パケットの兆候は見られません。

Wire-shark を使用して調査したところ、次のことがわかりました。

1. クライアントによる UDP パケットは、送信元ポート 58963 (変化し続ける) でポート 1234 の宛先に送信されます。

2. UDP 応答 (UDP サーバーから) も 58845 から 58963 に返されます。

3. これに続いて、ICMP Destination unreachable (Port unreachable) メッセージが続きます。

この動作の理由は何ですか?