問題タブ [eintr]

Ubuntu 10.04 で iwth gcc バージョン 4.4.3 をプログラミングしています。sigtimedwait()、sigwait() で SIGALRM をキャッチする方法がわかりません。

タイマー ハンドラが設定されている場合、sigtimedwait()、sigwait() は常に EINTR(4) を返します。タイマー ハンドラが設定されていない場合、SIGALRM は受信されません。

intel archでタスクがSIGALRMシグナルをキャッチするまで待つ方法はありますか?

タスクにソケットが含まれている場合、std::async を使用してタスクを並列実行するのに問題があります。

私のプログラムは、Linux 用の標準 C++ で書かれた単純な TCP ソケット サーバーです。クライアントが接続すると、専用のポートが開かれ、個別のスレッドが開始されるため、各クライアントは独自のスレッドで処理されます。

クライアント オブジェクトはマップに含まれています。

すべてのクライアントにメッセージをブロードキャストする機能があります。私はもともと以下のように書いていました：

これをテストしたところ、一度に 3 つのクライアントで動作します。メッセージは 3 つのクライアントすべてに (一度に 1 つずつ) 届き、応答文字列はこのループで 3 回出力されます。ただし、メッセージは一度に 1 つのクライアントにしか送信されないため、低速です。

より効率的にするために、std::async を利用して、すべてのクライアントに対して SendMessageToClient 関数を非同期的に呼び出すことを望んでいました。上記のコードを次のように書き直しました。

上記のコードは、マップ内にクライアントが 1 つしかない場合に期待どおりに機能します。「送信開始」に続いて「送信終了」がすぐに続き、すぐに「待機開始」が続き、3 秒後に (これをテストするためにクライアント応答側で 3 秒間スリープします)、ソケットからのトレースが表示されます。関数を読んで、応答が来ることを確認すると、「end wait」と表示されます

問題は、マップに複数のクライアントがある場合です。ソケットを開いて接続する SendMessageToClient 関数の部分で、以下のコードで失敗します。

出力は次のとおりです。「接続されたクライアント スレッド: 接続に失敗しました 4」。

このエラーコードを調べたところ、次のように説明されています。

私はインターネット上で検索しましたが、システムコールが信号によって中断されているという言及がいくつか見つかりました。

一度に1つずつメッセージ送信関数を呼び出すとこれが機能するのに、非同期を使用してメッセージ送信関数を呼び出すと失敗する理由を誰かが知っていますか? 複数のクライアントにメッセージを送信する方法について、別の提案がある人はいますか?

私のアプリケーションには 2 つのスレッドがあります。各スレッドは、各ソケットを介してサーバーからデータを受け取ります。スレッドは epoll_wait() を返すのを待ちます。epoll_wait() が -1 を返し、errno が EINTR になることがあります。EINTR は、システム call() がシグナルによって中断されたことを意味します。EINTRを処理するために追加しました。しかし、どんなシグナルが届いたのか、なぜシグナルが届いたのかはわかりません。かな。

方法 1.

スレッドを作成しました。

epoll_wait() が中断されたときにシグナルをキャッチできませんでした。

方法 2

アプリケーションを strace ツールで実行すると、epoll_wait() が中断されることはありません。

私の問題は GDB ツールで非常によく再現されています。助けが必要です....

私はそのようなCコードを持っています

このコードを実行すると、子プロセスがスリープしている間、親プロセスは待機します。ctrlここで ( +を押して) 親プログラムを中断するcと、UNIX (POSIX 標準) のドキュメントによると、wait 関数は -1 を返し、errno を EINTR に設定する必要があります。ただし、親プロセスが SIGINT シグナルを子プロセスに送信するため、私のコード実装は子プロセスを強制終了します。しかし、驚くべきことに、(親プロセスでは) wait は pid = -1 を返さず、errno は EINTR に設定されます。代わりに、強制終了された子プロセスの ID を返します。

これについての説明はありますか？

tl;dr

Python でパイプを読み取るときに、EINTR の「system call interrupted」エラーを処理する必要がありますか? その場合、そのようなコードをテストするにはどうすればよいですか?

説明

以下のトレースバックでself._dataqは、multiprocessing.Queue（技術的にはbilliardライブラリを使用していますが、基本的に同じコードだと思います）です。Python サブプロセスは、キューの反対側に書き込みを行うことがあります。何が起こったのかは、システム コールがキューにフィードするパイプを読み取っていて、シグナルが到着したことだと思います。おそらく、2 番目の Ctrl+C イベントからの SIGINT です (最初の SIGINT は、ユーザー^Cがロギング出力、およびシグナル ハンドラーがその SIGINT をキャッチしたことは、ログの WARNING メッセージで確認できます)。

上記のトレースバックのステートメントresult = self._dataq.get(timeout=0.1)は、次のようなループの途中にあります。ループの主な目的は、戻り始めるself._dataqときにからの読み取りをあきらめることができるようにすることです。self.timedout()True

質問

発生した理由についての私の理論IOErrorが正しい場合、上記のtry...ブロックは、システムコールの中断によって発生した sexceptをキャッチして無視する必要があります。IOErrorEINTR エラーの原因がシグナルである場合、Python に戻ってexcept IOError:ステートメントを実行するだけで、Python レベルのシグナル ハンドラーを実行できます。

あれは正しいですか？もしそうなら、私のコードでこの変更をテストすることは可能ですか? 深刻な競合状態を含まない単体テストをどのように作成するかは、私には明らかではありません。

次のことを手伝ってくれる専門家はいますか？

Cで次のシステムコールがあります：

エラー コード -1 および errno EINTR/EAGAIN で失敗する可能性があるかどうかを知りたいです。

これらの EINTR/EAGAIN を処理する必要がありますか?

ドキュメントには EINTR/EAGAIN に関する記述はありませんが、多くの人が EINTR/EAGAIN を扱っています。

どれが正しいですか？

シグナルハンドラーを登録する方法は次のとおりです。

この構成では: https://gitorious.org/zepto-web-server/zepto-web-server/source/b1b03b9ecccfe9646e34caf3eb04689e2bbc54dd:src/server-signals-support-utility.c

また、EINTRまたはEAGAINを返すことがわかっているいくつかのシステムコールにEINTR/EAGAIN処理を追加したコミットがあります:

この関数を含む C++ アプリケーションがあります。

select()通常、このコードは問題なく動作しますが、あるインスタンスで、コードで失敗し続ける無限ループに陥るのを見ましたEINTR errno。この場合、呼び出し元はタイムアウトを 0 秒と 0 マイクロ秒に設定しました。つまり、待機せずselect()にすぐに結果を返します。シグナルハンドラーが発生したときにのみ発生すると思っていEINTRましたが、シグナルハンドラーを何度も (12 時間以上) 取得し続けるのはなぜですか? これは Centos 5 です。これをデバッガーに入れて何が起こっているかを確認すると、数回の反復の後、コードは EINTR なしで返されました。チェックされる fd はソケットであることに注意してください。

上記のコードに再試行制限を追加することもできますが、まず何が起こっているのかを理解したいと思います。

この方法でファイルから整数を読み取っています。

信号が届くとどうなりますか? errno == EINTR を管理するにはどうすればよいですか? errno==EINTR の場合、読み取りを繰り返す必要がありますか?

だから私はかなり長い間fcloseマンページを勉強しています.私の結論は、マンページによると、fcloseが何らかの信号によって中断された場合、回復する方法はないということです...? 私はいくつかのポイントを逃していますか？

通常、バッファリングされていない POSIX 関数 (open、close、write など) では、呼び出しを再開することでシグナル割り込み (EINTR) から回復する方法が常にあります。対照的に、バッファリングされた呼び出しのドキュメントには、 fclose の試行が失敗した後、別の試行で未定義の動作が発生することが記載されています...代わりに回復する方法についてのヒントはありません。シグナルが fclose を中断した場合、私は「運が悪い」だけですか? データが失われる可能性があり、ファイル記述子が実際に閉じられているかどうかはわかりません。バッファが割り当て解除されていることは知っていますが、ファイル記述子はどうですか? 多数の fd を同時に使用し、fd が適切に解放されていない場合に問題が発生する大規模なアプリケーションについて考えてみてください -> この問題に対するクリーンな解決策が必要であると思います。

ライブラリを作成していて、sigaction と SA_RESTART の使用が許可されておらず、多くのシグナルが送信されていると仮定しましょう。fclose が中断された場合、どうすれば回復できますか? fclose が EINTR で失敗した後、(fclose の代わりに) ループで close を呼び出すのは良い考えでしょうか? fclose のドキュメントでは、ファイル記述子の状態について言及していません。ただし、 UNDEFINEDはあまり役に立ちません... fd が閉じられているときにもう一度 close を呼び出すと、デバッグが困難な奇妙な副作用が発生する可能性があるため、当然、このケースは間違ったことをしているので無視したいと思います...利用可能なファイル記述子の数に制限はなく、リソースのリークはある種のバグです (少なくとも私にとっては)。

もちろん、fclose の特定の実装を確認することはできますが、誰かが stdio を設計し、この問題について考えなかったとは信じられませんか? 悪いのはドキュメントだけですか、それともこの関数の設計ですか?

このコーナーケースは本当に私を悩ませます:(