問題タブ [setitimer]
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.
c - 複数のシグナルハンドラを使用しないコード
さまざまなシグナルを処理するために使用したいこのコードがあります。timer_handler2() に行かない理由がわかりません。timer_handler() に固執するだけです。誰かが私が間違っていることを親切に教えてくれますか
php - setitimerでITIMER_PROFを使用し、ITIMER_REALを使用しないのはなぜですか?
Linux の PHP は、setitimer で ITIMER_PROF を使用して ini(max_execution_time) と set_time_limit を実装しますが、ITIMER_REAL は使用しません。google it で、この質問https://bugs.php.net/bug.php?id=65596に関する php.net のスレッドを見つけました。PHPマニュアル関連http://php.net/manual/en/function.set-time-limit.php note
set_time_limit() 関数と構成ディレクティブ max_execution_time は、スクリプト自体の実行時間にのみ影響します。system() を使用したシステム コール、ストリーム操作、データベース クエリなど、スクリプトの実行以外で発生するアクティビティに費やされた時間は、スクリプトの最大実行時間を決定する際には含まれません。これは、測定時間が実数である Windows では当てはまりません。PHP は ITIMER_PROF を使用するように設計されているようです。
PHP タイムアウト メカニズムがそのように設計された理由を知りたいのですが、Zend/zend_execute_API.c で ITIMER_PROF を ITIMER_REAL に変更すると、どのような副作用が現れるでしょうか?
c - setitimer と dup2 が execvp の後に子プロセスに対して機能するのはなぜですか?
最初に言っておきますが、ここには多くの質問があります。
私の論文のタスクの 1 つは、サブプログラムを実行し、実行時間 (壁時間ではなく user+sys ) が特定の値を超えている場合、または RAM 消費量が別の値を超えている場合にそれを強制終了するプログラムを作成する必要があります。指定された値。
RAMの部分はまだわかりませんが。setitmer と ITIMER_PROF シグナルを使って時間をつぶします。(ITIMER_PROF は、開始時点を設定してから x の時間をカウントするのではなく、実際の CPU 使用率を収集するため)
setitimer を使用する理由は、必要な精度が 2 秒未満であるためです。(EG 1.75 秒 ( 1750000マイクロ秒) 後にプロセスを強制終了します。setrlimit メソッドには 1 秒の 1 つしかありません。
質問 1親プロセスで設定すると、ITIME_PROF を使用した setitimer が機能しないのはなぜですか? 子の CPU/システム コールは収集されませんか?
質問 2なぜこれが機能するのですか!? execvp はすべての関数 (timeout_sigprof、main およびその他) を上書きしませんか? そして、誰かが潜在的に子プログラムのシグナルをキャッチして、元の関数に取って代わることができませんでしたか?
質問 3ここに配置された dup2 が実際に動作し、子の入出力をリダイレクトできるのはなぜですか?
これは、X時間( x = 500ms )後に実行された後にのみ、プログラムを実行して強制終了する、私が書いたコードです。
どんな助け/説明も大歓迎です!
よろしくお願いします。
元
macos - sigaction および setitimer システム コールを使用して BSD/OS X にアセンブリ言語タイマーを実装する
sigaction() & setitimer() システム コールを使用して、OS X Lion の 32 ビット アセンブラでタイマー ルーチンを実装しようとしています。アイデアは、setitimer() を使用してタイマーを設定し、生成されたアラーム信号が、sigaction() によって以前に設定されたハンドラー関数を呼び出すようにすることです。私は Linux で動作するこのようなメカニズムを持っていますが、OS X で動作するようには見えません。OS X と Linux ではシステム コールの規則が異なり、OS X には 16 バイトのアラインメント要件があることを知っています。これらを補っているにもかかわらず、私はまだそれを機能させることができません (通常は "Bus error: 10" エラー)。アラインメントに何か問題があったと考えて、私が望むことを実行する単純な C プログラムを作成し、clang 3.2 を使用してアセンブリ コードを生成しました。次に、sigaction() & への呼び出しを置き換えることで、機械で生成されたアセンブリを変更しました。setitimer() に適切な system & int $0x80 呼び出し、およびスタック アライメント命令を使用します。結果のプログラムはまだ機能しません。
アセンブリの生成に使用した C プログラム sigaction.c を次に示します。結果のアセンブリコードが読みやすくなるように、 printf と sleep をコメントアウトしたことに注意してください。
}
上記のファイルで「clang -arch i386 -S sigaction.c」を使用して生成されたアセンブリ コードを次に示します。
「clang -arch i386 sigaction.s -o sigaction」を使用してアセンブリ コードをコンパイルし、lldb を使用してデバッグし、ハンドラ関数にブレークポイントを配置すると、実際にハンドラ関数が毎秒呼び出されます。したがって、アセンブリ コードが正しいことはわかっています (C コードについても同様です)。
sigaction() の呼び出しを次のように置き換えると:
および setitimer() の呼び出し:
アセンブリ コードが機能しなくなり、手動でコーディングしたアセンブリ コードと同じ "Bus error: 10" が生成されます。
スタックをアラインするために使用している subl/addl 命令を削除し、値を変更してスタックが 16 バイト境界にアラインされるようにしましたが、何も機能していないようです。バス エラー、セグメンテーション フォールトが発生するか、ハンドラー関数を呼び出さずにコードがハングします。
デバッグ中に気づいたことの 1 つは、sigaction 呼び出しが、基になるシステム コールの周りに長いラッパーを持っているように見えることです。lldb 内から両方の関数を逆アセンブルすると、sigaction() には長いラッパーがありますが、setitimer にはありません。これが何かを意味するかどうかはわかりませんが、sigaction() ラッパーがデータを渡す前にデータを処理している可能性があります。そのコードをデバッグしようとしましたが、まだ決定的なものは見つかりませんでした。
sigaction() および setitimer() 関数を適切なシステム コールに置き換えることで、上記のアセンブリ コードを機能させる方法を知っている人がいれば、大歓迎です。次に、これらの変更を取得して、手作業でコーディングしたルーチンに適用できます。
ありがとう。
更新: 手書きのアセンブリ コードを扱いやすいサイズに縮小し、sigaction() & setitimer() ライブラリ呼び出しを使用して動作させることができましたが、syscall が動作しない理由はまだわかりません。コードは次のとおりです(timer.s):
「clang -arch i386 timer.s -o timer」でコンパイルし、lldb でデバッグすると、ハンドラー ルーチンが毎秒呼び出されます。コード内の syscall を使用してコードを機能させる努力をやめました。それらは sigaction() および setitimer() 呼び出しの周りでコメントアウトされています。自分自身 (および他の人) を教育する以外の理由がない場合でも、可能であればシステム コールのバージョンを機能させたいと考えています。
再度、感謝します。
更新 2: setitimer syscall が機能するようになりました。変更されたコードは次のとおりです。
しかし、同じ編集は sigaction sys コールでは機能しません。これにより、最初の結論に戻ります。sigaction() ライブラリ関数は、実際の syscall を行う前に特別なことを行っています。dtruss からのこのスニペットは、同じことを示唆しているようです:
sigaction() syscall を使用 (動作していません):
sigaction() ライブラリ呼び出し (動作中):
ご覧のとおり、2 つのバージョンで 2 番目の引数が異なります。syscallではsigaction構造体(0x2030)のアドレスがそのまま渡されているようですが、ライブラリコールでは別のものが渡されています。「何か他のもの」が sigaction() ライブラリ関数で生成されていると推測しています。
更新 3: FreeBSD 9.1 にもまったく同じ問題が存在することがわかりました。setitimer システムコールは機能しますが、sigaction システムコールは機能しません。OS X と同様に、sigaction() ライブラリ呼び出しは機能します。
BSD にはいくつかの sigaction syscall があります。これまでのところ、OS X で使用していたのと同じ 0x2e のみを試しました。おそらく、他の sigaction システムコールの 1 つが機能するでしょう。BSD にも同じ動作があることを知っていれば、C ソース コードを引っ張ることができるので、追跡が容易になります。さらに、これにより、問題が何であるかをすでに知っている可能性のある、より幅広い人々のグループに問題が開かれます。
syscall がどのように機能するかについての私の理解と、Linux で sigaction が機能するという事実に基づいて考えると、自分のコードで何か間違ったことをしていると思わざるを得ません。ただし、 int $0x80 呼び出しを sigaction() ライブラリ関数に置き換えるとコードが機能するという事実は、これと矛盾しているようです。FreeBSD 開発者マニュアルには、アセンブリ言語プログラミングに関する章全体と、システム コールの作成に関するセクションがあるため、私が行っていることが可能になるはずです。
https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86-system-calls.html
誰かが私が間違っていることを指摘できない限り、次のステップは sigaction() の BSD ソースを調べることだと思います。前に述べたように、OS X で sigaction の逆アセンブル バージョンを調べたところ、他のシステム コールに比べて非常に長く、マジック ナンバーでいっぱいであることがわかりました。うまくいけば、C コードを見ることで、それが機能する原因が明らかになるでしょう。最終的には、間違った sigaction 構造体 (いくつかあります) を渡すか、どこかにビットを設定するのに失敗するなど、単純なことである可能性があります。
c - タイマーを 30 秒間実行する
毎秒30秒間タイマーをトリガーしたい。ただし、タイマーは 1 回だけトリガーされ、プログラムは停止します。タイマーを 30 秒間実行するにはどうすればよいですか?
c - C での getitimer と setitimer の使用
getitimer と setitimer を使用して単純な操作を実行するのにかかる時間を取得するために、次の C コードを作成しています。
私はコンパイルしました:
ただし、私の答えは常に 999999 です (100 を上げ下げしました)。
私のエラーは何ですか?また、このようなプログラムを使用して得られる最高の精度はどれくらいですか?
どうもありがとう!
c - SIGALRM が waitpid() を中断しないようにする
子プロセスのプロセスを作成しようとしていますwaitpid()
が、間隔ごとに何かを出力します。
私の現在の計画はitimer
、印刷をwaitpid()
処理し、終了 SIGALRM
時にタイマーを停止することです。waitpid()
私が理解できない唯一の部分は、 がSIGALRM
を中断しないようにすることwaitpid()
です。
マニュアルページを調べましたが、これに関するフラグはありません。
考え?