(注意)このブログは本家のほうの文章部分のみの転載です．ソースコードの配布，画像などについては本家のほうを参照してください．文章中のリンク先は面倒なのですべて本家のほうに変換してしまっているのでご注意ください．
突然だけど，Toppersの最新カーネルをちょっと興味本位で読んでみた．そしたらLinux用シミュレータの実装で，setjmp()/longjmp() を利用してスレッドのディスパッチをしていてびっくり．使い方もほとんど同じ．うーん，誰でも考えることは同じなんだなあ．．．(けっこう良いアイディアだと思っていたのだが，誰でも考えつくようなものってことか．．．)
さて，ここまではあまり難しいことは考えずにてきとーーーに作ってきていて，なんだこんなの楽勝じゃんっていうか，なにも考えなくてもよさそうに思えてしまうのだけど，実際には排他とか再入とかいったことを考えなければならない．
たとえば前々回の実装では，複数のスレッドから何も考えずに fprintf() を呼び出していたが，これは問題は無いのか？
また前々々回の実装では，kz_send() によるメッセージ送信でも，スタック上に確保している文字列を平気で送ってしまっていた．これは問題は無いのか？
結論から言うとどちらも問題がある．というより，問題がある可能性がある．まあでも「問題がある可能性がある」というその時点で職業プログラマなら「ほんとうに問題が無いのか？」を調査しなければならなくなる．つまり，扱いはバグと同じになってしまう．
たとえば fprintf() だが，複数のスレッドから呼ばれてしまっている．ということは，fprintf() の呼び出し中に別のスレッドがタイマ割り込みとかでディスパッチして fprintf() が再度呼ばれる，ということがありうるわけだ．この際に，もしも fprintf() 関数の内部で
のようにして，文字列の処理用のバッファを静的に(static に)確保していたらどうなるだろうか？こういうのは，スタックサイズを節約したい組み込み機器では十分にあり得ることだ．
あるスレッドが fprintf() による処理中にタイマ割り込みが入り，別のスレッドがディスパッチされ，そちらのスレッドでも fprintf() が行われてしまう．この際に上記バッファの内容は上書きされてしまうため，最初に動いていたスレッドが再度ディスパッチされたときには，バッファの内容が書き変わってしまっている．結果として，最初に動いていたスレッドからすれば，とつぜんバッファの内容が壊れてしまって見えることになる．これはまんまバグに直結するが，症状が症状なので，非常に原因を特定しにくいバグの原因になる．
このように，ある関数の処理中に再度その関数が(別スレッドなどから)呼ばれてしまうことは関数の再入と呼ばれる．関数の内部で静的変数の書き換えをしていると，上で説明したように，関数が再入された際に誤動作することになる．
プロセスモデルだと，仮想メモリ機構によってプロセス単位で資源が確保されるのでこのような問題は起きない(注:シグナル処理を除く．このためシグナルハンドラからライブラリ関数を無闇に呼んではいけない)のだが，スレッドプログラミングではスレッドのディスパッチが頻繁に起きるのと，資源は共通化されるので，このような再入はあたりまえのように起きることになる．で，いくつか対策はあるのだが，まず代表的な対策として
関数を再入可能にするならば，その関数だけでなく，その関数の内部から呼ばれるライブラリ関数も芋ヅル式に再入可能になっていないと意味が無い．よって再入可能にするためには，関数単位でなくライブラリ単位での対処が必要になる．とはいっても最近のライブラリはスレッドでの利用を考慮して，ライブラリ全体として再入可能になっているものも多い．こーいうのは「このライブラリはスレッドセーフになっているため，スレッドプログラミングで利用することも可能である」などと説明されることもある．
もうひとつの方法として，
で，ここまではまあ対策の方法で思いつくものを書いてみたのだけど．．．
まず FreeBSD の fprintf() がスレッドセーフかどうかという点なのだけど，ちょっとよくわからない．こーいうのは実装によって異なるので，FreeBSD と Linux ではとーぜん違うことが考えられるし，まあ調べればわかることなのだけど，調べてないしよく知らん．またスレッドセーフでないとしても，現状の実装では，上で説明したような優先度などの関係で，構造的に再入が起きない，ということもあり得る．このへんはほんとはちゃんと検証しなければならないのだけど，面倒なのでここでは検証していない．そーいう意味で，冒頭では「問題がある」ではなく「問題がある*可能性がある*」という表現をしている．
でも「問題がある可能性がある」ということは，言い方を変えれば，「問題が無いことを調べてはっきりさせるか，別の実装方法に変更する必要がある」ということだ．
結局のところこれらの問題は，スレッド間で共通の資源をどうするかということなのだけど，実は共通資源の扱いに関しては，一番良いというか，まあだいたいこーしとけば間違いは無いというまともな対策がある．それは，
まず前者について説明しよう．fprintf() による表示をすべてのスレッドで許可するのではなく，fprintf() を行う専用のスレッドを作成し，各スレッドはメッセージの出力が行いたいならば，自分で fprintf() を呼び出すのではなく，その専用スレッドにメッセージを投げて，出力を「お願いする」というものだ．
次に後者だが，これは簡単だ．そのサービスを行うためのシステムコールを作成し，OSに行わせる，というものだ．ただしこれをやるとOSがサービス過剰で肥大化しがちになるので，注意と取捨選択が必要だ．
前者では共通資源の利用は専用スレッドにお願いしたが，後者ではOSにお願いすることになる．いずれにしても，共通資源をアクセスするコンテキストはひとつに絞る，というのがミソになる．そもそも資源がひとつならば，それをアクセスするひともひとつであるべき(そしてそのひとにお願いするべき)という考え方だ．
ではここで，上記の前者，後者の設計で，前回の fprintf() による文字列表示プログラムを書き換えてみよう．まず，以下のような設計にする．
ここで，outlogスレッドになげるメッセージを kz_memalloc() によって獲得している(そしてoutlogスレッド側で kz_memfree() により解放している)という点に注目してほしい．冒頭で言及したように，前々々回の実装では，スタック上に確保している文字列を送っていた．しかしこれは実は問題があって，たとえば文字列表示スレッドにデータとしてスタック上の文字列を送った場合，もしも文字列表示スレッドのほうが優先度が低くて，さらに送信もとのほうが関数から抜けてしまったりすると，スタックが解放されてしまい，実際の文字列表示の際にスタック上の文字列が残っているかどうか保証できない．ていうか，たまになんかおかしな文字列が表示されるとかいった，これはこれで原因が特定しにくいバグの原因になり得る．こーいうのはスレッドの優先度構成が変わったり，スレッド間のメッセージのやりとりの手順が変わったり，関数の呼び出し構造を変えたり関数呼び出しを新たに追加したりすることで突然発生したりするのでやっかいだ(なのでやはりこれも，冒頭では「問題がある」ではなく「問題がある可能性がある」という表現をしている)．なので outlog スレッドに送る文字列データは静的なものにするか，kz_memalloc()によって確保したものにする(そして kz_memfree() 側で解放する)かのどちらかになる．しかし文字列データを静的なものにするとして，outlog スレッドを利用する立場(ユーザー側の立場)からすると，
のような使い方はOKなのだけど，
のような使い方はNG(かもしれない)ということになる．正確には，後者の書き方で優先度がoutlogよりも高くて関数から抜けるとスタック解放されるのでアウト，ということになる(スタック上書きされなくても，シグナル処理で非同期にスタックが汚れる可能性がある)．
で，前者のような書き方はいいのだけれど，それを見て，何も考えずに後者のような書き方をするひとが必ず出てくる．複数人での大規模開発だとこーいうミスはすごくあり得る．
まあそいつの無知といってしまうとそこまでだし，心配ならば仕様書に注意書きしておけばいいといえばそこまでなのだけど，みなさんはこーいうミスについて，どう考えるでしょうか？
こーいうミスに対して「そんなの，スレッド構成もちゃんと理解せずに，スタックを使ってしまう無知な輩が悪い」「仕様書に書いてないのが悪い」「仕様書をちゃんと読まないのが悪い」というのは簡単だし，実際そーいうことを平気で言ったりする人もいたりするのだけど，ぼくのコーディング時のテーマは「いかに安全に書くか？(自分も，他人も)」ということであり，(無知の人が無知のままでもいいとは思わないが)たとえ無知だとしても，それによりバグが出ることが予想されるような設計をわざわざすることもない．というか，そーいう設計は積極的に避けるべきだ．近頃はどこでも開発サイクルはどんどん短縮化されているし，人の出入りも激しい．しかしソースコードの規模はどんどん肥大化している(数ヵ月で数10万行なんて，ザラだと思う)．そのような開発環境で，新しく参加したメンバーでも極力バグを出さなくてすむ，注意しなければならない事柄を減らす，調べなければならない範囲を狭めるような考慮というのは，非常に大切だ．
まあこのへんは個人的な考えになってしまうが，ここでちょっとぼくのバグに対する考え方をだらだらと書いてみるけど，たとえば自動車の運転がうまいというのは，ハンドリングがうまいとか交差点でのコーナリングがうまいとか駐車車両よけるのがうまいとか加速がうまいとか単にクルマの操作がうまいとかそーいうことよりも，周りの状況がきちんと見れて交通の流れを適切に先読みできる，あの車や歩行者はどうしたいんだろうとか，人の考えていることを読める(良い意味で読める，ということ．勝手に憶測して決めつけるということではない)，危険を予測できる(駐車車両よけるのが下手ならば，そもそも駐車車両があるだろうことを予測して，そこには行かないとかあらかじめ距離を取るとかができる)，前や隣を走っているのがあまり運転のうまくない人でも，事故が起こらないようにうまく位置取りができる(もしくはそういう位置取りをさせてあげられる)ように流れを作れる，とかいったことだと思うのだな．あ，もちろんレースとかでなく，公道で，の話ね．だって公道では，前や隣を走っているのがみんな運転うまい人だとは限らないわけだし，ひょっとしたら初心者かもしれないわけじゃないですか．それでもしも事故ってしまって，万が一大怪我なんてしてしまったとしたら，もうどっちが悪いとか悪くないとか，運転がうまいとか下手だとかいった以前の問題になってしまうわけです．で，プログラミングも共同作業であるわけで，同じことだと思うのですな．
スポーツでも，ファインプレーがあるうちはまだ２流で，１流はそもそもファインプレーなんぞしなくていいように流れを作る，というじゃないですか．個人的には，そういう考え方と言うか，周りを見た(他人に優しい)書き方ができないうちは上級プログラマにはなれん！と思う．(言語を扱えるようになっただけでその言語をマスターしたと思ってしまううちは，まだまだ上級ではないというか，先は長いと思う)
ということで，ここでは文字列表示を依頼する側で kz_memalloc() によりメモリ獲得し，outlog スレッドで kz_memfree() によるメモリ解放する，という設計にする．文字列表示のたびにいちいち kz_memalloc() して strcpy()するのが面倒だというならば，そのためのライブラリ関数を一個作ればいいだけだ．
で，結局やることは outlog スレッドの追加と kz_memalloc()/kz_memfree() の追加ということになる．修正後のソースは以下．今回は outlog.c が追加されている．以下は前回からの差分．すでにいっぱい説明してしまったので，ソースについてあまり説明する部分は無い．kz_memalloc()/kz_memfree()に関しては，実際には malloc()/free() を行うだけのシステムコールを追加しただけだ．
outlogスレッドのメイン処理は outlog.c にあり，以下のようになっている．
kz_recv()でメッセージの受信待ちをして，fprintf()で表示して，kz_memfree()で解放するだけだ．
サンプルプログラムによって動作確認する．main.c は前回のものを以下のように改造している．
kz_memalloc()によりメモリ獲得し，strcpy()でデータをコピーし，kz_send()により outlog スレッドに送信する．メモリの解放は outlog スレッド側で行われるので，ここで行う必要は無い．
なお outlog スレッドはログの表示用に今後も利用する．このように一般的に利用されるようなサービスに関してはスレッド化して，スレッドの機能として提供する，というのがKOZOSの方針でもある．
以下は実行結果．
前回と同様に，ちゃんと表示が行われている．
突然だけど，Toppersの最新カーネルをちょっと興味本位で読んでみた．そしたらLinux用シミュレータの実装で，setjmp()/longjmp() を利用してスレッドのディスパッチをしていてびっくり．使い方もほとんど同じ．うーん，誰でも考えることは同じなんだなあ．．．(けっこう良いアイディアだと思っていたのだが，誰でも考えつくようなものってことか．．．)
さて，ここまではあまり難しいことは考えずにてきとーーーに作ってきていて，なんだこんなの楽勝じゃんっていうか，なにも考えなくてもよさそうに思えてしまうのだけど，実際には排他とか再入とかいったことを考えなければならない．
たとえば前々回の実装では，複数のスレッドから何も考えずに fprintf() を呼び出していたが，これは問題は無いのか？
また前々々回の実装では，kz_send() によるメッセージ送信でも，スタック上に確保している文字列を平気で送ってしまっていた．これは問題は無いのか？
結論から言うとどちらも問題がある．というより，問題がある可能性がある．まあでも「問題がある可能性がある」というその時点で職業プログラマなら「ほんとうに問題が無いのか？」を調査しなければならなくなる．つまり，扱いはバグと同じになってしまう．
たとえば fprintf() だが，複数のスレッドから呼ばれてしまっている．ということは，fprintf() の呼び出し中に別のスレッドがタイマ割り込みとかでディスパッチして fprintf() が再度呼ばれる，ということがありうるわけだ．この際に，もしも fprintf() 関数の内部で
int fprintf(FILE *fp, const char *fmt, ...)
{
static char buf[1024];
...
のようにして，文字列の処理用のバッファを静的に(static に)確保していたらどうなるだろうか？こういうのは，スタックサイズを節約したい組み込み機器では十分にあり得ることだ．
あるスレッドが fprintf() による処理中にタイマ割り込みが入り，別のスレッドがディスパッチされ，そちらのスレッドでも fprintf() が行われてしまう．この際に上記バッファの内容は上書きされてしまうため，最初に動いていたスレッドが再度ディスパッチされたときには，バッファの内容が書き変わってしまっている．結果として，最初に動いていたスレッドからすれば，とつぜんバッファの内容が壊れてしまって見えることになる．これはまんまバグに直結するが，症状が症状なので，非常に原因を特定しにくいバグの原因になる．
このように，ある関数の処理中に再度その関数が(別スレッドなどから)呼ばれてしまうことは関数の再入と呼ばれる．関数の内部で静的変数の書き換えをしていると，上で説明したように，関数が再入された際に誤動作することになる．
プロセスモデルだと，仮想メモリ機構によってプロセス単位で資源が確保されるのでこのような問題は起きない(注:シグナル処理を除く．このためシグナルハンドラからライブラリ関数を無闇に呼んではいけない)のだが，スレッドプログラミングではスレッドのディスパッチが頻繁に起きるのと，資源は共通化されるので，このような再入はあたりまえのように起きることになる．で，いくつか対策はあるのだが，まず代表的な対策として
- 静的変数(グローバル変数などもダメ)は一切利用せず，ローカル変数のみ利用する．
関数を再入可能にするならば，その関数だけでなく，その関数の内部から呼ばれるライブラリ関数も芋ヅル式に再入可能になっていないと意味が無い．よって再入可能にするためには，関数単位でなくライブラリ単位での対処が必要になる．とはいっても最近のライブラリはスレッドでの利用を考慮して，ライブラリ全体として再入可能になっているものも多い．こーいうのは「このライブラリはスレッドセーフになっているため，スレッドプログラミングで利用することも可能である」などと説明されることもある．
もうひとつの方法として，
- オブジェクト指向を導入し，スレッド単位でログ出力用のオブジェクトを作成し，実際の出力時にはオブジェクトに対して出力処理を行う．(資源はオブジェクト単位で確保されるので，資源がぶつかることは無い)
- スレッドの構成や優先度を工夫することで，再入されることが無いような設計にする．
- 共通資源のアクセス時には，割り込み禁止，優先度変更，セマフォの利用などで排他を行う．
で，ここまではまあ対策の方法で思いつくものを書いてみたのだけど．．．
まず FreeBSD の fprintf() がスレッドセーフかどうかという点なのだけど，ちょっとよくわからない．こーいうのは実装によって異なるので，FreeBSD と Linux ではとーぜん違うことが考えられるし，まあ調べればわかることなのだけど，調べてないしよく知らん．またスレッドセーフでないとしても，現状の実装では，上で説明したような優先度などの関係で，構造的に再入が起きない，ということもあり得る．このへんはほんとはちゃんと検証しなければならないのだけど，面倒なのでここでは検証していない．そーいう意味で，冒頭では「問題がある」ではなく「問題がある*可能性がある*」という表現をしている．
でも「問題がある可能性がある」ということは，言い方を変えれば，「問題が無いことを調べてはっきりさせるか，別の実装方法に変更する必要がある」ということだ．
結局のところこれらの問題は，スレッド間で共通の資源をどうするかということなのだけど，実は共通資源の扱いに関しては，一番良いというか，まあだいたいこーしとけば間違いは無いというまともな対策がある．それは，
- 共通資源をアクセスするための専用スレッドを作成し，その資源へのアクセスはそのスレッドに限らせる．
- 共通資源の管理はすべてOSにまかせる．
まず前者について説明しよう．fprintf() による表示をすべてのスレッドで許可するのではなく，fprintf() を行う専用のスレッドを作成し，各スレッドはメッセージの出力が行いたいならば，自分で fprintf() を呼び出すのではなく，その専用スレッドにメッセージを投げて，出力を「お願いする」というものだ．
次に後者だが，これは簡単だ．そのサービスを行うためのシステムコールを作成し，OSに行わせる，というものだ．ただしこれをやるとOSがサービス過剰で肥大化しがちになるので，注意と取捨選択が必要だ．
前者では共通資源の利用は専用スレッドにお願いしたが，後者ではOSにお願いすることになる．いずれにしても，共通資源をアクセスするコンテキストはひとつに絞る，というのがミソになる．そもそも資源がひとつならば，それをアクセスするひともひとつであるべき(そしてそのひとにお願いするべき)という考え方だ．
ではここで，上記の前者，後者の設計で，前回の fprintf() による文字列表示プログラムを書き換えてみよう．まず，以下のような設計にする．
- 文字列の表示用に outlog というスレッドを起動し，文字列を出力したい場合にはoutlog スレッドに kz_send() によってメッセージを送って「お願い」する．
- メモリ獲得・解放用に kz_memalloc()/kz_memfree() を追加する．上記メッセージの送信時には，kz_memalloc()によってメモリを獲得する．
ここで，outlogスレッドになげるメッセージを kz_memalloc() によって獲得している(そしてoutlogスレッド側で kz_memfree() により解放している)という点に注目してほしい．冒頭で言及したように，前々々回の実装では，スタック上に確保している文字列を送っていた．しかしこれは実は問題があって，たとえば文字列表示スレッドにデータとしてスタック上の文字列を送った場合，もしも文字列表示スレッドのほうが優先度が低くて，さらに送信もとのほうが関数から抜けてしまったりすると，スタックが解放されてしまい，実際の文字列表示の際にスタック上の文字列が残っているかどうか保証できない．ていうか，たまになんかおかしな文字列が表示されるとかいった，これはこれで原因が特定しにくいバグの原因になり得る．こーいうのはスレッドの優先度構成が変わったり，スレッド間のメッセージのやりとりの手順が変わったり，関数の呼び出し構造を変えたり関数呼び出しを新たに追加したりすることで突然発生したりするのでやっかいだ(なのでやはりこれも，冒頭では「問題がある」ではなく「問題がある可能性がある」という表現をしている)．なので outlog スレッドに送る文字列データは静的なものにするか，kz_memalloc()によって確保したものにする(そして kz_memfree() 側で解放する)かのどちらかになる．しかし文字列データを静的なものにするとして，outlog スレッドを利用する立場(ユーザー側の立場)からすると，
char *p = "message"; /* これは静的領域なのでOK */
kz_send(outlog_id, strlen(p), p);
のような使い方はOKなのだけど，
char p[] = "message"; /* これはスタック上なのでNG */
kz_send(outlog_id, strlen(p), p);
のような使い方はNG(かもしれない)ということになる．正確には，後者の書き方で優先度がoutlogよりも高くて関数から抜けるとスタック解放されるのでアウト，ということになる(スタック上書きされなくても，シグナル処理で非同期にスタックが汚れる可能性がある)．
で，前者のような書き方はいいのだけれど，それを見て，何も考えずに後者のような書き方をするひとが必ず出てくる．複数人での大規模開発だとこーいうミスはすごくあり得る．
まあそいつの無知といってしまうとそこまでだし，心配ならば仕様書に注意書きしておけばいいといえばそこまでなのだけど，みなさんはこーいうミスについて，どう考えるでしょうか？
こーいうミスに対して「そんなの，スレッド構成もちゃんと理解せずに，スタックを使ってしまう無知な輩が悪い」「仕様書に書いてないのが悪い」「仕様書をちゃんと読まないのが悪い」というのは簡単だし，実際そーいうことを平気で言ったりする人もいたりするのだけど，ぼくのコーディング時のテーマは「いかに安全に書くか？(自分も，他人も)」ということであり，(無知の人が無知のままでもいいとは思わないが)たとえ無知だとしても，それによりバグが出ることが予想されるような設計をわざわざすることもない．というか，そーいう設計は積極的に避けるべきだ．近頃はどこでも開発サイクルはどんどん短縮化されているし，人の出入りも激しい．しかしソースコードの規模はどんどん肥大化している(数ヵ月で数10万行なんて，ザラだと思う)．そのような開発環境で，新しく参加したメンバーでも極力バグを出さなくてすむ，注意しなければならない事柄を減らす，調べなければならない範囲を狭めるような考慮というのは，非常に大切だ．
まあこのへんは個人的な考えになってしまうが，ここでちょっとぼくのバグに対する考え方をだらだらと書いてみるけど，たとえば自動車の運転がうまいというのは，ハンドリングがうまいとか交差点でのコーナリングがうまいとか駐車車両よけるのがうまいとか加速がうまいとか単にクルマの操作がうまいとかそーいうことよりも，周りの状況がきちんと見れて交通の流れを適切に先読みできる，あの車や歩行者はどうしたいんだろうとか，人の考えていることを読める(良い意味で読める，ということ．勝手に憶測して決めつけるということではない)，危険を予測できる(駐車車両よけるのが下手ならば，そもそも駐車車両があるだろうことを予測して，そこには行かないとかあらかじめ距離を取るとかができる)，前や隣を走っているのがあまり運転のうまくない人でも，事故が起こらないようにうまく位置取りができる(もしくはそういう位置取りをさせてあげられる)ように流れを作れる，とかいったことだと思うのだな．あ，もちろんレースとかでなく，公道で，の話ね．だって公道では，前や隣を走っているのがみんな運転うまい人だとは限らないわけだし，ひょっとしたら初心者かもしれないわけじゃないですか．それでもしも事故ってしまって，万が一大怪我なんてしてしまったとしたら，もうどっちが悪いとか悪くないとか，運転がうまいとか下手だとかいった以前の問題になってしまうわけです．で，プログラミングも共同作業であるわけで，同じことだと思うのですな．
スポーツでも，ファインプレーがあるうちはまだ２流で，１流はそもそもファインプレーなんぞしなくていいように流れを作る，というじゃないですか．個人的には，そういう考え方と言うか，周りを見た(他人に優しい)書き方ができないうちは上級プログラマにはなれん！と思う．(言語を扱えるようになっただけでその言語をマスターしたと思ってしまううちは，まだまだ上級ではないというか，先は長いと思う)
ということで，ここでは文字列表示を依頼する側で kz_memalloc() によりメモリ獲得し，outlog スレッドで kz_memfree() によるメモリ解放する，という設計にする．文字列表示のたびにいちいち kz_memalloc() して strcpy()するのが面倒だというならば，そのためのライブラリ関数を一個作ればいいだけだ．
で，結局やることは outlog スレッドの追加と kz_memalloc()/kz_memfree() の追加ということになる．修正後のソースは以下．今回は outlog.c が追加されている．以下は前回からの差分．すでにいっぱい説明してしまったので，ソースについてあまり説明する部分は無い．kz_memalloc()/kz_memfree()に関しては，実際には malloc()/free() を行うだけのシステムコールを追加しただけだ．
outlogスレッドのメイン処理は outlog.c にあり，以下のようになっている．
int outlog_main(int argc, char *argv[])
{
char *p;
while (1) {
kz_recv(NULL, &p);
fprintf(stderr, "%s", p);
kz_memfree(p);
}
}
kz_recv()でメッセージの受信待ちをして，fprintf()で表示して，kz_memfree()で解放するだけだ．
サンプルプログラムによって動作確認する．main.c は前回のものを以下のように改造している．
int mainfunc1(int argc, char *argv[])
{
char *p, *mes = "func1\n";
while (1) {
p = kz_memalloc(strlen(mes) + 1);
strcpy(p, mes);
kz_send(outlog_id, 0, p);
kz_timer(100);
kz_recv(NULL, NULL);
}
return 0;
}
kz_memalloc()によりメモリ獲得し，strcpy()でデータをコピーし，kz_send()により outlog スレッドに送信する．メモリの解放は outlog スレッド側で行われるので，ここで行う必要は無い．
なお outlog スレッドはログの表示用に今後も利用する．このように一般的に利用されるようなサービスに関してはスレッド化して，スレッドの機能として提供する，というのがKOZOSの方針でもある．
以下は実行結果．
% ./koz
func1
func2
func3
func1
func2
func3
func1
func2
func1
func3
func1
func2
func3
func1
func2
func1
func3
^C
%
前回と同様に，ちゃんと表示が行われている．