実装に誤りがあったので修正。プログラムをしているとつい忘れてしまうのがスレッドのスタックオーバーフローの問題。スタック領域を持っているため、よほどのことがない限りスタックが溢れてしまうことはない。積極的に使うようなプログラムではスタックオーバーフローを気にすべきだ。スタックのオーバーフローが起きた場合でもプログラム中で事故処理を行い、適切にリカバリーできるようにしたい。スレッドが生成された時に所定のサイズの仮想メモリ空間が割り付けられる。これがスタックが取りうる最大サイズになる。実際には、仮想メモリの仕組みを利用してスタックの最初のページにだけ実メモリが割り付けられる。実行が進みスタックが伸びてくるとメモリが割り当てられていないメモリページへアクセスが起きる。ハンドリングしてスタックの未マップ領域にメモリを割り当てることになる。ユーザープロセスからは隠蔽されている。構造化例外がスローされる。スタックオーバーフローをハンドリングする方法について述べる。系についても少しだけ書く。Stack)スタックオーバーのハンドリングのためには代替シグナルスタックを設定する必要がある。シグナルを補足した場合、シグナルハンドラにバイオレーションが発生したアドレスが渡される。スタックの存在するアドレス範囲を把握する必要がある。スタックを本当に使い切ってしまうとまずい。そのためスタックに「余白」を作る必要がある。登録された復帰ポイントに強制的に戻る方法について述べる。シグナルを補足する必要がある。シグナルを補足するようにできている(ものがほとんどだ)。例外が発生した場合には、シグナルハンドラを呼び出すスタックフレームを置くメモリがないということになる。これはシグナルハンドラが予め用意された通常とは異なるスタックを使用する機構である。代替シグナルスタックは明示的に設定を行った時にのみ利用される。同様の機構がデフォルトで用意されている。呼び出す処理を行ってもよい。0;}この時点ではまだシグナルをハンドラしただけで、スタックオーバーフローに対処したとはいえない。以下のような問題がある。スタックオーバーフローとそうでない場合の切り分けが必要。一度スタックオーバーフローを起こしたコンテキストに戻る必要がある。スタックオーバーフローのままである。異なる場所から実行を再開したい場合がある。このコードは正しく動作しない。スタック領域情報の取得スレッドのスタックがメモリ上のどこにあるか判定する方法について述べる。スタック事情は大変複雑だ。スレッドの特性は、使用されるスレッドライブラリによって大きく変わってくる。複数のプロセスとして実装。管理スレッドを必要とする。複数のプロセスとして実装。管理スレッドを必要とする。スタックサイズを自由に選択できる。カーネルレベルでのスレッドのサポート。準拠に同期オブジェクトのカーネルサポート同一プロセスのスレッドが同じプロセスIDを持つようになった。スタックサイズを自由に選択できる。使われなくなっているので、さすがに気にしなくてもよいと思われる。