スタックオーバーフローのハンドリング (Stack Overflow Handling)
作成日：2004.04.12 更新日：2006.02.19 更新記録 (2004.04.12) 3/6、 3/11、 3/13 の日記をまとめて作成。 (2004.05.07) 文章を修正。サンプルコードを追加。 (2005.01.20) alternative → alterante に修正。 (2005.02.13) 追記を記述。 (2006.02.17) linux_stack_info.cpp の実装に誤りがあったので修正。 (2006.02.19) BSD 系OS でのスタック領域情報の取得の仕方を追加 初めに C/C++ でプログラムをしているとつい忘れてしまうのがスレッドのスタックオーバーフローの問題。 最近の OS はスレッド当たり 2〜8MB のスタック領域を持っているため、よほどのことがない限りスタックが溢れてしまうことはない。 だが、再帰や alloca を積極的に使
Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき
前回までの続き。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会をまだ読んでいる。遅読。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき 今回は、Unixプロセスとシグナルの基礎について再確認していく。 Unixシグナル・事始め Unixシグナルの「いろは」 シグナルを再定義する シグナルハンドリングの注意点 Unixシグナル・事始め 前回、子プロセスの終了を待ち受けるのに用いた Process.wait は、実行するとそこで自身（親プロセス）の処理を止めて子プロセスの終了を待った。これは ブロッキング呼び出し と呼ばれる。 では「親は親で何か別の仕事をしたいとき」はどうするかというと、これから見ていくシグナルを上手に使うと実
Rubyのシグナルハンドラ - tmtms のメモ
toRuby & guRuby 出張版 でシグナルについてやってたので、関連して書いてみます。 どのような時にシグナルハンドラを定義するのか どのような時にシグナルハンドラを定義するのかという話がありました。 UNIXのデーモンプログラムは、何が由来なのかわかりませんが、SIGHUP で設定ファイルの再読み込みを行うのが慣習になっています。 SIGHUP はデフォルト動作ではプログラムを終了させてしまうだけなので、SIGHUP で特別な処理を行いたいプログラムはシグナルハンドラを定義しています。 本来 SIGHUP は端末が終了した時に端末上で動いていたプログラムに対してOSが発行するためのものです。 たとえば、端末エミュレータを開いて、 % sleep 9999 と実行してる状態で端末エミュレータを閉じると sleep プロセスに SIGHUP が送られます。別の端末から strace
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What does signal(SIGCHLD, SIG_DFL); mean?
Why restoring signal handlers is important
