問題タブ [signal-handling]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
multithreading - Linuxでシグナルハンドラの実行はプリエンプティブルではありませんか?
p
のシグナルハンドラに登録されたプロセスがありますSIGALRM
。SIGALRM
processに定期的にシグナルを送信するようにタイマーが設定されますp
。また、複数のスレッドがプロセスで実行されていますp
。トリガーされて実行されたときのシグナルハンドラは、プリエンプティブルではないですか? というか、シグナルハンドラの実行は処理中のどのスレッドにも割り込まれないということp
ですか?
PS: シグナル ハンドラーはカーネルで実行されると思いましたが (そうですか?)、カーネルはユーザー モード スレッドに対してプリエンプティブではありませんか? 違っていたら訂正...
unix - Unix/Linux: SIGCONT/SIGTSTP のハンドラ
現在、シグナルを使用してプログラムを書いていますが、次のような問題があります。
SIGSTOP
/を送信せずに、実行中のプログラムの状態を停止/実行中に変更するにはどうすればよいSIGCONT
ですか?
私は、私が使用する必要があることを理解しています:
と
しかし、現在実行中のプロセスの構造 task_struct を取得する方法は?
また:私がする必要があるのはそれだけです(これらの2つの関数を呼び出す)。
前もって感謝します!
c - Cのパイプが機能しないのはなぜですか?
演習として、シグナルハンドラーを使用し、シグナルを取得するときに2つのプロセス間でいくつかのメッセージを送信するためにパイプを使用する必要があります。以下は私のソースコードです。実行しているときは、パイプを機能させることができます。メインメソッド(この場合はprocess1()とprocess2())でパイプを呼び出す限り、両方のプロセスが通信できます。しかし、私はシグナルハンドラー内のパイプを使用したいと思います。しかし、今ではパイプは機能しません。これは私が得たいくつかの出力です:
'898'と'130'は等しいはずですが、そうではありません。私はパイプが正しく機能していることを知っているので、それは信号物と関係があると思います...しかし何...?
ソースコード:
c++ - C++ でのシグナル処理
型の引数は型void (*)(int)
のパラメーターと互換性がありません__sighnd64_t
以下は私の簡単なコードです:
私はopenvmsに取り組んでいます。ある種の型キャストでコンパイル エラーを回避できますか? 私のコンパイラは `__sighnd64_t __64_signal(int, __sighnd64_t); を期待しています。
ハンドラ extern c を追加するとうまくいきました。ありがとう
c++ - C++ の例外とシグナル ハンドラ
Bjarne Stroustrup によるThe Design and Evolution of C++ を読んでいます。例外処理と非同期シグナルに関しては、以下のように言及されています。
シグナルなどを処理するために例外を使用できますか? ほとんどの C 環境ではそうではありません。問題は、C が再入可能ではない malloc のような関数を使用することです。malloc の途中で割り込みが発生して例外が発生した場合、例外ハンドラが malloc を再度実行するのを防ぐ方法はありません。
呼び出しシーケンスとランタイム ライブラリ全体が再入可能性の要件に合わせて設計されている C++ 実装では、シグナルが例外をスローできるようになります。
「例外ハンドラが malloc を再度実行するのを防ぐ方法はない」という文の著者の意味は何ですか? 関数を再入可能にすると、どのようにしてシグナル ハンドラから例外をスローできるようになりますか?
linux - コールスタックでmalloc/freeを使用したシグナルハンドラーからのLinux 64ビットでのバックトレース
以下は、「Red Hat Enterprise Linux 5.5 (Tikanga) Kernel 2.6.18-194.el5xen x86_64」OS を実行しているマシンで使用したいソースの例です。
一般的な考え方は、いくつかのスレッドのバックトレースが必要なため、そのスレッドの SIGUSR1 シグナルを発生させ、ハンドラーが backtrace() 呼び出しを行うというものです。
以下の私のシナリオでは、FrameTwo 関数は malloc と free をループで呼び出します。この特定のスレッドに対してシグナルが発生し、free または malloc が呼び出しスタックにある場合は常に、シグナル ハンドラーが backtrace() を呼び出すと、プログラムがクラッシュします。
バックトレースをシグナルハンドラから呼び出すべきではないことを他のソースから学んだので、この場合のために独自の関数 grok_and_print_thread_stack() を作成しました。
RBP レジスタを使用してスタックをナビゲートします (RBP には、前のフレームのベース ポインタを指す現在のフレームのベース ポインタが含まれています) が、このアルゴリズムはこの場合も機能しません: _int_free () がコールスタックにある場合、RBP _int_free の RBP が有効なフレームのベース ポインターではない 0x20 のような値であるため、レジスタ ナビゲーション アルゴリズムが壊れます。
レジスタからコールスタックをナビゲートする方法を知っている人はいますか? または、バックトレースを目的に使用するにはどうすればよいですか?
c - 複製されたスレッドでのシグナルの送信と処理
更新: これはタイミングの問題のようです。kill の呼び出しの前に sleep の呼び出しを追加すると、すべてが期待どおりに機能します。
私は clone(2) で遊んでいて、それがどのように機能するかを理解しようとしています。現在、複製されたプロセスにシグナルを送信する際に問題が発生しています。次のコードがあります。
次の出力が得られます。
子は明らかにシグナルの結果として殺されましたが、シグナルハンドラが呼び出されなかったのはなぜですか?
linux - ターミナルで ctrl-x を使用すると、どのシグナルが送信されますか?
Linux/Unix にはシグナルがあります。( CtrlC)SIGINT
は私には明らかです。CtrlXさて、他のいくつかのアプリケーションでは、 ?!経由のシグナルがあります。それはシグナルですか、それともエスケープシーケンスを生成しますか? CtrlC( CtrlV、CtrlX...)に似たものとして使用できるものは他にありますか?
誰かが手がかりを持っている場合、私はbashよりもCに精通していますが、両方の言語での回答は大歓迎です!
c - Ncurses: F1 キーが押されたかどうかを検出し、シグナルを使用する
ncurses ライブラリを学習しようとしていますが、以下のコードを思いつきました:
このコードの問題は、F1 キーを押すと、端末のヘルプ ウィンドウが開き、F1 キーを押しても認識されないことです。また、シグナルメカニズムによってctrl + cプレスをキャッチできません。ターミナルで F1 キーをオーバーライドする方法はありますか? curses モードでシグナルを使用するにはどうすればよいですか?
c - 非同期シグナルハンドラは Linux でどのように実行されますか?
Linux で非同期シグナル ハンドラーの実行がどのように機能するかを正確に知りたいです。まず、どのスレッドがシグナル ハンドラを実行しているかがわかりません。次に、スレッドにシグナル ハンドラを実行させるための手順を知りたいです。
最初の問題について、一見相反するように見える 2 つの異なる説明を読みました。
The Linux Kernel, by Andries Brouwer, §5.2「シグナルの受信」には次のように記載されています。
シグナルが到着すると、プロセスが中断され、現在のレジスタが保存され、シグナル ハンドラが呼び出されます。シグナル ハンドラーが戻ると、中断されたアクティビティが続行されます。
StackOverflowの質問「マルチスレッド プログラムでの非同期シグナルの処理」により、Linux の動作はSCO Unix の動作に似ていると思います。
シグナルがプロセスに配信されるとき、シグナルがキャッチされている場合は、次の条件のいずれかを満たすスレッドの 1 つだけによって処理されます。
キャッチされたシグナルのタイプが引数に含まれている sigwait (2) システムコールでブロックされたスレッド。
キャッチされたシグナルのタイプがシグナルマスクに含まれていないスレッド。
その他の考慮事項:
- sigwait (2)でブロックされたスレッドは、シグナル タイプをブロックしていないスレッドよりも優先されます。
- 複数のスレッドがこれらの要件を満たす場合 (おそらく 2 つのスレッドがsigwait (2)を呼び出している場合)、そのうちの 1 つが選択されます。この選択は、アプリケーション プログラムでは予測できません。
- 適切なスレッドがない場合、スレッドが適切になるまで、シグナルはプロセスレベルで「保留中」のままになります。
また、Moshe Bar による「The Linux Signals Handling Model」には、 「非同期シグナルは、シグナルをブロックしていないことが判明した最初のスレッドに配信されます」と記載されています。 .
どちらが正しいですか?
2 つ目の問題として、選択したスレッドのスタックとレジスタの内容はどうなるでしょうか。シグナルハンドラーを実行するスレッドTが関数の実行中にあるとしdo_stuff()
ます。スレッドTのスタックは、シグナル ハンドラを実行するために直接使用されますか (つまり、シグナル トランポリンのアドレスがTのスタックにプッシュされ、制御フローがシグナル ハンドラに移動します)。または、別のスタックが使用されていますか? それはどのように機能しますか?