ファイルを使った抽象化機能
本文にも書いたように、Unix系OSではソケットとファイルの記述子(ディスクリプタ)が共通化されています。特に、ソケットを最初に実装したBSD(Berkley Software Distribution)バージョンでは、それが徹底されています。もともと、データの入出力先をすべてファイルとして扱うのがUnixの基本思想です。Unixでは、OSが扱うデータは全て構造を持たないバイト列として表現され(注1)、データの入出力処理はファイルに対する読み書きとして行うのが基本です。つまり、データの入出力対象をファイルによって抽象化しているのです。
「データの入出力対象をファイルによって抽象化する」というのは、すべてのデータ入出力操作を一種類のシステムコール、すなわちread()とwrite()によって行えるということです。その利点は、システムコール(API)の体系がシンプルで理解しやすいということに尽きます。システムの構成要素を表わす概念、すなわち構成概念が少ないということは、それだけ理解すべき項目が少なくて済むということだからです。
他の例でいえば、BeOSのメッセージ通信がそうです。BeOSでは、BMessageオブジェクトを使ったメッセージ通信が至る所で使われいます。そして、異なるアプリケーション同士の間でメッセージをやり取りするアプリケーション間通信と、同じアプリケーションの中でスレッド同士が行うスレッド間通信とが、BMessengerオブジェクトに対するSendMessage()メソッドの呼び出しで行えることを見ました。忘れてしまった人は、第8章の説明を読み返してみて下さい。
話しをソケットに戻しましょう。Unix系OSのソケットAPIとは違い、WinSockや、それに倣ったBeOSのソケットAPIでは、ネットワークに対する入出力とファイルに対する入出力を共通に扱うことができず、それだけ抽象度の低いものになってしまっているのです。これは、もしかするとBeOSの魅力を下げるものかも知れません。特に、1997年頃から一部で注目を浴びている"Inferno"というOSと比べると、それを強く感じます。Infernoは、Unixの産みの親であるAT&Tベル研究所のDenis Ritchieらによって開発されたOSで(注2)、ファイルによる抽象化を徹底して押し進めているのが特徴です。
とはいえ、構造を持たないデータの入出力よりも、もう一段高いレベルの処理、つまりフラット化されていないデータの入出力について考えれば、BeOSも十分な抽象化機能を備えています。それが、BMessageとBMessengerを使ったメッセージ通信です。BMessengerオブジェクトを使えば、実際の宛先とするBHandlerオブジェクトが同じアプリケーションの中にあるのか、あるいは他のアプリケーション内に存在しているのかに関係なくメッセージを送ることができます。さらに、BMessageオブジェクトのデータコンテナ機能が多様なデータの扱いを可能にしています。つまり、BeOSではオブジェクト間のデータ転送が、BMessageによるメッセージ通信として抽象化されていると言えるでしょう。第10章で説明したレプリカント機構では、オブジェクト自体をメッセージによって転送することすら行われているのです。
OSカーネルレベルの抽象化機構においては、BeOSはUnix系OSやInfernoに劣るところがあるものの、高機能のアプリケーションを開発する基盤としては、十分な抽象化機構を持っていると言えるのではないでしょうか。
注1:「OSが扱うデータは全て構造を持たない」という表現は、実際は正しくありません。より正確に言うと、「アプリケーションがOSを介してやり取りするデータ」ということです。つまり、すべてのデータはフラット化された形で入出力が行われ、その内容を解釈するのはアプリケーションに任されているのです。
注2:現在は、Infernoの開発はベル研究所からLucent Technologies, Inc.に移管されています。
Art of BeOS Programming
koga@stprec.co.jp