>> (1)よりつづく

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[ サンプルコード ]

子プロセスの同期/非同期

4epoll、5epoll-multiへのダミー処理追加には、いくつかの注意点があります。1baseと同じように、epollによるイベントループがその場で子プロセスの終了を待つようにすると、1つのダミー処理の終了を他のセッションが待つことになってしまいます。 これはepollによる、イベントループのI/Oの多重性を損なう大きな問題です（ 図1.9 ）。

図1.9 epoll の多重性を損ねるダミー処理追加

（セッションCは割愛）

「インターネットサーバでのPthreadとepoll」の記事（以下、前記事と呼びます）を書いた時点では、手元の環境がプアなためマルチプロセス/マルチスレッドを採用したサンプルプログラムの真価を発揮させられず、適切に比較できませんでしたが、その後デュアルコアマシンを借りることができたので、改めて比較してみました。 また、比較の際にサンプルプログラムに追加したダミー処理ではシグナルも使用したので、やはりLinuxに追加された signalfd(2) もepollによるイベントループで処理してみました。

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[ サンプルコード ]

前記事のサンプルプログラム

前記事 ではHTTPサーバを例に並列性/多重性のサンプル実装を5種類提示しました。簡単に振り返ります。サンプルプログラムがデュアルコアシステム上で動作しており、HTTPリクエストがほぼ同時に3件届いた場合のインタリーブ例を挙げてみます。毎回必ずこの通りにインタリーブされるわけではなく、あくまでもそれぞれの動作の違いを示すための一例です（ 図1.1 から 図1.5 ）。 また、5epoll-multiはCPU数-1個の4epoll（相当）を子プロセスとして起動しますが、デュアルコアシステムでは子プロセスの4epollを1つしか起動せず、4epollとの比較がしにくくなるため、今回は測定用にCPU数分の4epollの子プロセスを起動することにします。

>>（1）よりつづく
前回は単純な実装からマルチスレッド、スレッドプールと順に見て行きました。今回はいよいよepollを使った実装を紹介します。

本連載ではシステムコールプログラミングの例も掲載していく予定ですが、本記事ではLinuxに追加されたepollを採りあげ、インターネットサーバでのPthread利用と比較してみます。

UnionMount

AUFS/UnionFSがunion内のメンバをディレクトリとするのに対し、UnionMountでのメンバはブロックデバイス（すなわちマウントとしてunion機能実装)です。もっとも大きな違いはその実装方針にあり、UnionMountはより上位に位置するVFS内でunion機能を実現しようとしています( 図6 ）。

ファイルシステムとしてのunion実装と比較すると、VFS内でメンバ内から処理対象を選択決定する点が大きく異なります。このため、 vfs_mkdir() などVFSヘルパ関数を再度コールする必要がなくなります。

「神の書」として知られる『ActionScript 3.0 アニメーション』の著者、Keith Peters氏の最新作『詳解 ActionScript 3.0アニメーション――衝突判定・AI・3DからピクセルシェーダまでFlash上級テクニック』が、1月23日、ついにオライリー・ジャパンから発売されました。発売がアナウンスされた直後、なんと予約だけでAmazon.co.jpのPC書ランキング入りを果たすなど、ActionScriptユーザーの熱い注目を集めています。 昨年11月に来日された際には、オライリー・ジャパンのオフィスにも立ち寄っていただきました（写真はその際のものです。Keithさんの左胸に注目！）。とても物静かで真摯なお人柄に、オライリーのスタッフも一目でファンになってしまいました。
今回、この『詳解 ActionScript 3.0アニメーション』刊行に先立って、Keithさんにメールインタビューを行いました。Keithさんのプライベートから、「神の書」と呼ばれるほどの書籍を書くまでに読んできた書籍や学習法などについてお話していただいております。

ラムダ

目立つ機能としては、「->」によるラムダ（λ）を入れたり、「.()」による呼び出しを入れたということですね、やっぱり関数型言語の影響が大きく、ラムダをこんな記号（->）で導入しました。

― まずこの話があったときは、まず最初に何があったかというと、「ラムダ」って書きづらいと。

1.8だとラムダメソッドってのがあって、lambdaだっけ、（綴りに）自信がないけど。Lispの人たちはそれこそ湯水のように使うけれど、普通のプログラマにはなじみがないし、読みにくい、書きにくい、長いメソッド名どうよって話があって。

あと、メソッドって再定義できるじゃないですか。「lambda」って書いても、本当にラムダを返すのか自信がない。ラムダじゃないものが返せてしまうかもしれない。いろんな最適化のことを考えると、こういうものは言語組み込みであった方がうれしいよねって思って、この2点から新しい記法を取り入れました。
ただエライ不評で、「この記号λに見えないじゃん」って。ターミナルっぽいフォントで表示して横に傾けるとλに見える、って言うとみんな笑ってくれるけど、それでも迫害は止まらないんです。

Ruby 1.9では文字列の抽象度が上がった

Ruby 1.8ではすべてがバイト列だったんです。で、Ruby 1.9ではコードポイント¹と対になっている文字を表現するようになりました。ちょっと抽象度があがりました。

ですから、これからは"ABCあいう"という文字列の0番目を取ると「A」という文字を返します。で、3文字目から1文字を取ると、変なバイトではなくて「あ」という文字を返します。

― 3番目というのはゼロから数えて3番目のことですね。

ゼロから...皆さん分かりますよね。数字はゼロから数えますよね。

Ruby 1.8とRuby 1.9は非互換です。その中には大きなものから小さなものまであって、その中でも重要なのは「ブロックパラメータ」「文字列」「M17N」です。

ブロックパラメータ

Rubyにはブロックというものがあります。縦棒（｜）の中に変数があって、（直前に書かれたイテレータの各要素が）渡されパラメータとして代入される。これはもともとループの抽象化として誕生したので、棒の間はループの各要素が代入される場所だったんです。（ブロックパラメータは）任意の変数、つまりグローバル変数でも、ローカル変数でも、配列でも大丈夫。何でも置けたんです。

ところが1.9からはちょっと変わっていて、グローバル変数を置こうとするともうダメ。これまではオブジェクトの属性に代入できたり、配列のスライスを呼び出せたのも、できなくなりました。それと同時に、（ブロックパラメータに指定された）ローカル変数のスコープは、ブロックの範囲内にとどまるということ。xに15を代入してループにパラメータを用意して、xに10を代入する。1.8では、ブロックの外側のxと内側のxは同じものなので、10に書き変わったんですね。だけど1．9からはブロックの中身なので、同じ名前だけど違うものになったとみなして数が変わらない。

5章 文と制御構造

Rubyって文と式とあんまり区別がないんですけど、普通のプログラミング言語で文といわれているようなものとか、制御構造と言われているものについて解説しています。

―この辺から発展的内容って感じですね、4章までは、どちらかと言えばRubyの基礎的な内容でしたが、ここからですね、なんて言うんですかブレーキが外れてきて、

ははは。

―この章の一番最後の方にスレッドとかファイバとか継続について書いてあるんですけど、ファイバに関して言うと、この本の原著が最初に出たのが2008年1月。このころは、まだファイバが出てきたばかりで、これ本当に書くのか？ という感じで。2007年の11月に飛行機の中でドラフト版を読んで「ファイバに何ページも割いてある」と言ったら、（まつもとさんに）「ちょ、ちょっと見せて」とか言われて。まだ当時そんなに固まってないのに「こんなに書かれるとヤバい」と。

ファイバ作っている本人でさえ嫌がると。

―日本語版では、まつもとさんの「まえがき」という重要な部分が

日本語版ではまえがきを書いていて、すこし貢献度があがったと。

－みなさん、ぜひまつもとさんのまえがきを読んでいただいて...

はい。前書き作家としての（活躍を）ですね。僕がまえがき書くと本が売れるんですよ。『Googleを支える技術』¹、去年のベストセラー。その前は『Code Reading』²、あれも前書き書いてるんですよ。今年はこれでベストセラーを狙います。まえがき書いても全然印税入んないんですけど。まえがきとオビ（の推薦文）で知名度を上げるべく頑張っております。

『プログラミング言語Ruby』のヘンなところ

この本って、結構オライリー的には変わった本で、とさっきオライリーの人から聞いたんですけど、1つはタイトルが『The Ruby Programing Language』って書いてあるんです。

―原著ですね。

こっち（日本語版）でも『プログラミング言語Ruby』となっていて、他の、オライリーの他の本で、こういう『Programing Language』というタイトルの本がほかにない。

―例えばPerlだと『Programming Perl』ですね。

あれが原典ですね。Pythonは『Programming Python』。

―『JavaScript』とか『CVS』（のようなもの）もありますね。

そう、ソフトウェアの名前そのままというのはありますけど。

―そういえば『The Ruby Programing Language』みたいなのはあまりないですね。

そうですね。もっともピッケル本が「プログラミングRuby」なので、書名をとられちゃったという理由があるのかもしれないですけれど。

驚きの共著者が登場『The Ruby Programming Language』

それで『Ruby in a Nutshell』の後、そのまま長らくなかったことになっている感じだったのですが、ある日、2007年だったと思いますけれども、オライリーの編集者から久しぶりにメールが来てですね、「in a Nutshellの新しい本を作りたいんだ」と。Rubyも大分広まったし（今の）「in a Nutshell」は薄いからと。でも「お前が書くのは無理だろうから」って、分かってらっしゃる。

で、ですね、「共著者を用意するから」という風に言われて、まあ、僕が書けないのは分かっているので、「これをベースに誰か書いてくれればそれに越したことはないけれど」と思っていた。次のメールが来て「（共著者を）見つけて来たから。David Flanagan」。聞いたことのある名前だなあって。

まつもとゆきひろです。Rubyというプログラミング言語を作った人です。『プログラミング言語Ruby』という本の共著者ということになっています。かなり名前だけですが。

ここから始まった『Rubyデスクトップリファレンス』

最初の最初から話をするとですね、奥付を調べたら2000年11月21日と書いてあったので、もう9年も前ですね。本を出したんです。『Rubyデスクトップリファレンス』っていう本です。本当はポケットリファレンスという、今でもあるのかな？ ポケットリファレンスという本（のシリーズ）が出てたんですけれど、妙に厚くなってポケットには入らないということで、デスクトップリファレンスに急遽なったという、いわくつきの本です。当時出たばかりのRuby 1.6というバージョンに対応していました。