クライアントサーバという究極の設計思想：Symbian OS開発の勘所（8）（3/4 ページ）

[大久保 潤 管理工学研究所，＠IT MONOist]

非同期API

　しかしクライアントサイドAPIがクライアントサーバをうまくラッピングしてくれるとはいえ、クライアントが何も考えなくてもよいわけではありません。前節に引き続き、ファイルサーバを題材に解説を行います。

　ファイルサーバの機能のうち、ファイルを開いて内容を操作する部分に関してはRFileというクライアントサイドAPIに集約されています。この定義の抜粋を以下に示します。

図5　RFileの概要

　Read()やWrite()という見慣れたAPIが並んでいますが、しかしよく見ればそれぞれTRequestStatus& aStatus引数を持ったバリアントも存在しています。これがこの節のポイントです。

　第6回、第7回で解説したとおり、システムの応答性や省電力性を高めるためには非同期処理が欠かせません。時間がかかる処理を他制御に依頼した結果、ユーザーからの指示が受けられないようでは困るわけです。では、他制御とは誰なのか？ マイクロカーネルOSであるSymbian OSでは、デバイスドライバを直接たたいて結果を待つのでなければ、他制御とは一般にサーバを指します。

　というわけで、要求に対する処理が短時間で完了しない可能性がある場合、サーバは非同期APIを公開します。サーバとしても、時間がかかる処理でクライアントをブロックさせるのは本意ではないわけで、そのためにアクティブオブジェクトとアクティブスケジューラが必要であれば、それが使えるインターフェイスを提供します。非同期APIを見分けるポイントは引数にTRequestStatus&があるかないかで、ここに渡されるべきものはもちろんCActiveクラスのiStatusメンバ変数です。クライアントもその点を斟酌（しんしゃく）して、非同期APIが公開されていればアクティブオブジェクトによるラッピングを検討すべきです。

　ちなみに「非同期APIを公開」と微妙ないい回しを使ったのは、同期APIの実装とは「非同期API相当を発行＋シングルウェイト」であることによります。つまりクライアントサーバ間の要求と応答は本質的には非同期で、我慢できる範囲（もしくは割り切りが期待できる範囲）に限ってシングルウェイトを内部発行する疑似同期APIが用意されるのです。

　最後にこの節のまとめとして押さえておきたいのは、クライアントサーバだから非同期対応が必要になったのではないということです。何をいっているのだ、と思われるかもしれませんが、非同期APIを使わなければいけないのはクライアントサーバのせいだ、という因果関係が逆転した誤解を耳にすることがあるのです。

　繰り返しになりますが、非同期性・非同期処理はモバイル端末には欠かせないものであること、そしてサーバは比較的粒度の大きい要求を処理する場所であること、この2つが相まってサーバが提供するクライアントサイドAPIに非同期が顔を出すことになっています。が、モノリシックOSであっても非同期処理が必要なのであれば、やはりカーネルが提供するRead() APIには非同期バージョンが用意されるでしょうし、クライアントとしても非同期処理を検討することになるでしょう。

Over the client-side API and far away.

　次に視点を変えて、クライアントサイドAPIの向こう側で行われていることを見てみましょう。

　マイクロカーネルOSではカーネルはメッセージパッシング機能の提供に徹し、ユーザーはそれを使ってエンティティ間（Symbian OSの場合はクライアントとサーバ）の通信を行い、サービスを構築していくことになります。先に説明したRFsを使うサンプルコードの向こう側でも、これが行われています。

図6　クライアントサーバの通信／（※）ファイルサーバの中核クラスをCFsServerとし、CServer2から直接派生している図としましたが、実際はこれとは異なっています。あくまでも概念としてとらえてください

　図6にあるとおり、ファイルサーバに対してRFs経由で要求を発行しています（1. 要求）。また、サーバはユーザープロセスに対してその結果を返しています（2. 完了通知）。ユーザープロセスから見ると、サーバとの間にはこれらのやりとりを通す、「メッセージを用いた論理的な通信路」で示されるチャネルが張られているように見えます。

リクエストを他所に振り分けるための仕掛けとしては大げさじゃない？ セマフォ（注4）と共有メモリがあれば同じことをもっと軽く作れるよ

　そのような突っ込みが聞こえてきそうですが、果たして本当でしょうか。

※注4：

何かあるとすぐ「セマフォを使えば……」という態度のことを、弊社ではセマフォ万能伝説と呼んでいます。セマフォが必須の機能であることは論を待ちませんが、むき出しで使うにはあまりにもプリミティブ過ぎ、ほかの制御が仮定している環境を踏みにじるコードを簡単に書けてしまいます。