(57)【要約】【課題】第１のＡＰＩを有する第１のプラットフォームと、第２のＡＰＩを有する第２のプラットフォームにおける前記第２のＡＰＩと前記第１のＡＰＩとの間の差異を吸収するラッパーと、を備えた情報処理装置において、第１のプラットフォームのシステムコールで生成されたタスクがラッパーで生成されたシステムコールを呼び出せるようにする。【解決手段】第１のタスク１０１は、第１のＯＳ２１のシステムコール１１０により生成されたタスクであり、第１のＯＳ２１のシステムコール１１０を呼び出せるが、第２のＯＳのラッパー２２のシステムコール１２０は呼び出せない。仲介タスク１０３は、システムコール１１０及びシステムコール１２０を呼び出せる。仲介タスク１０３は、第１のタスク１０１と通信を行うときは、システムコール１１０を使用し、第２のタスク１０２と通信を行うときは、システムコール１２０を使用する。【選択図】図４
2015148836.tif 000002
【特許請求の範囲】
【請求項１】
第１のＡＰＩを有する第１のプラットフォームと、第２のＡＰＩを有する第２のプラットフォームにおける前記第２のＡＰＩと前記第１のＡＰＩとの間の差異を吸収するラッパーと、前記第１のプラットフォームのシステムコール及び前記ラッパーのシステムコールの呼び出しが可能な仲介タスクと、を有し、
前記仲介タスクは、前記第１のプラットフォームで生成されたタスクである第１のタスクと通信を行うときは、前記第１のプラットフォームのシステムコールを使用し、前記ラッパーで生成されたタスクである第２のタスクと通信を行うときは、前記ラッパーのシステムコールを使用する、情報処理装置。
【請求項２】
請求項１に記載された情報処理装置において、
前記仲介タスクは、前記第１のタスクから、前記第１のプラットフォームのシステムコールを使用して送信されたリクエストを受信するリクエスト受信手段と、前記受信されたリクエストに応じて、前記ラッパーのシステムコールを呼び出し、該システムコールを使用して、前記第２のタスクとの間で前記リクエストの送信及び結果の受信を行う通信手段と、前記第１のプラットフォームのシステムコールを呼び出し、該システムコールを使用して、前記結果を前記第１のタスクへ送信する結果送信手段と、を有する情報処理装置。
【請求項３】
請求項１に記載された情報処理装置において、
前記仲介タスクは、前記ラッパーのシステムコールで生成されたタスクである、情報処理装置。
【請求項４】
第１のＡＰＩを有する第１のプラットフォームと、第２のＡＰＩを有する第２のプラットフォームにおける前記第２のＡＰＩと前記第１のＡＰＩとの間の差異を吸収するラッパーと、を有する情報処理装置により実行される情報処理方法であって、
前記第１のプラットフォームのシステムコール及び前記ラッパーのシステムコールの呼び出しが可能な仲介タスクが、前記第１のプラットフォームのシステムコールで生成された第１のタスクとの間で、前記第１のプラットフォームのシステムコールを使用して通信を行う工程と、
前記仲介タスクが、前記ラッパーのシステムコールで生成された第２のタスクとの間で、前記ラッパーのシステムコールを使用して通信を行う工程と、を有する情報処理方法。
【請求項５】
コンピュータに、請求項４に記載された情報処理方法の各工程を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
オペレーティングシステム（Operating System；以下、ＯＳ）やミドルウェア等のコンピュータ・プラットフォーム上で動作するアプリケーションプログラム（以下、アプリケーション）を開発するため、命令や関数、規約等からなるアプリケーション・プログラミング・インターフェース（Application Programming Interface：以下、ＡＰＩ）が提供されている。アプリケーションの開発者は、プログラム上での所望の機能に対応するＡＰＩを呼び出すことにより、アプリケーションに当該機能を搭載することができる。
【０００３】
世の中には種々の異なるコンピュータ・プラットフォーム（以下、プラットフォーム）が存在する。そして、ある特定のプラットフォーム用に開発されたアプリケーションは、そのままでは他のプラットフォーム上で動作させることができないという問題がある。
【０００４】
ただし、次の２つのいずれかの方法によって、あるプラットフォーム用に開発されたアプリケーションが、別のプラットフォームで動作可能となる。第１の方法は、アプリケーションで呼び出すＡＰＩを、移植先のＯＳのＡＰＩに書き換える方法である。第２の方法は、アプリケーションと移植先のＯＳの間に、移植元のＡＰＩを移植先のＡＰＩに変換するラッパープログラム（以下、ラッパー）を設け、当該ラッパーを経由して移植先のＯＳのＡＰＩを呼び出す方法である。
【０００５】
第１の方法の場合、アプリケーションから直接、移植先のＯＳのＡＰＩを呼び出すため、オーバーヘッドが少なく、使用するメモリ容量も抑えられる。ただし、その反面、既に移植元のＯＳで動作実績のあるアプリケーションに対して修正を行うため、不具合が混入してしまう可能性があり、アプリケーションの検証が新たに必要になる。
【０００６】
一方、第２の方法の場合、移植元のＯＳのＡＰＩを移植先のＯＳのＡＰＩに変換するラッパー関数を用意するため、アプリケーションを修正する必要がない。ただし、その半面、アプリケーション実行時のオーバーヘッドが大きくなり消費するメモリ容量は第１の方法より大きくなる。しかしながら、動作実績のある信頼性が高いアプリケーションに変更を加える必要がないため、不具合が発生した時の問題箇所の特定が容易である。また、各ＡＰＩのラッパーを用意すればよいため、アプリケーション内のＡＰＩを全て書き換える第１の方法よりも、工数が削減され効率的な移植が可能となる。このため、第２の方法がより用いられる（例えば特許文献１）。
【０００７】
図９は、従来のラッパーの作用について説明するための図である。
図９Ａに示すように、プラットフォーム−Ａ用に開発されたアプリケーション−Ａはプラットフォーム−ＡのＡＰＩ（ＡＰＩ−Ａ）に合わせて作られているため、プラットフォーム−ＡのＯＳ（ＯＳ−Ａ）上で実行できる。
【０００８】
しかし、図９Ｂに示すように、アプリケーション−Ａをプラットフォーム−Ｂに持っていった場合、そのままではプラットフォーム−ＢのＡＰＩ（ＡＰＩ−Ｂ）には合わないため、アプリケーション−Ａを実行することができない。
【０００９】
そこで、図９Ｃに示すように、プラットフォーム−ＢにおいてＡＰＩ−ＡとＡＰＩ−Ｂの違いを吸収するためのライブラリ（ＡＰＩラッパー）を設け、アプリケーション−Ａを当該ライブラリとリンクすることにより、アプリケーション−Ａを修正することなしに、プラットフォーム−Ｂ上で動作させることができるようになる。このように、ＡＰＩラッパーは２つの異なるプラットフォーム間のＡＰＩの違いを吸収する役割を果たしている。
【００１０】
しかし、上記従来のＡＰＩラッパー（以下、ラッパー）では、プラットフォーム−ＢのＯＳ（ＯＳ−Ｂ）のシステムコール（ＡＰＩの一種）により生成されたタスクは、ラッパーのシステムコールを呼び出せないという問題がある。その理由は、ラッパーは、システムコールの管理情報（ＴＣＢ：Task Control Block）を用意しており、ラッパーのシステムコールで生成されたタスクにはラッパーのシステムコールの管理情報が付属しているのに対し、ＯＳ−Ｂのシステムコールで生成されたタスクにはラッパーのシステムコールの管理情報が付属していないからである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明はこのような問題を解決するためになされたものであり、その目的は、第１のＡＰＩを有する第１のプラットフォームと、第２のＡＰＩを有する第２のプラットフォームにおける前記第２のＡＰＩと前記第１のＡＰＩとの間の差異を吸収するラッパーと、を備えた情報処理装置において、第１のプラットフォームのシステムコールで生成されたタスクがラッパーで生成されたシステムコールを呼び出せるようにすることである。
【課題を解決するための手段】
【００１２】
本発明の情報処理装置は、第１のＡＰＩを有する第１のプラットフォームと、第２のＡＰＩを有する第２のプラットフォームにおける前記第２のＡＰＩと前記第１のＡＰＩとの間の差異を吸収するラッパーと、前記第１のプラットフォームのシステムコール及び前記ラッパーのシステムコールの呼び出しが可能な仲介タスクと、を有し、前記仲介タスクは、前記第１のプラットフォームで生成されたタスクである第１のタスクと通信を行うときは、前記第１のプラットフォームのシステムコールを使用し、前記ラッパーで生成されたタスクである第２のタスクと通信を行うときは、前記ラッパーのシステムコールを使用する、情報処理装置である。
【発明の効果】
【００１３】
本発明によれば、第１のＡＰＩを有する第１のプラットフォームと、第２のＡＰＩを有する第２のプラットフォームにおける前記第２のＡＰＩと前記第１のＡＰＩとの間の差異を吸収するラッパーと、を備えた情報処理装置において、第１のプラットフォームのシステムコールで生成されたタスクがラッパーで生成されたシステムコールを呼び出すことができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る情報処理装置のブロック図である。
【図２】本発明の実施形態に係る情報処理装置に実装されているソフトウェア群を示す図である。
【図３】本発明の実施形態に係る情報処理装置におけるタスクとシステムコールとの関係を示す図である。
【図４】本発明の実施形態に係る情報処理装置における仲介タスクの作用を説明するための図である。
【図５】本発明の実施形態に係る情報処理装置が印刷データを受信した時のソフトウェア群の動作を示すシーケンス図である。
【図６】図５におけるネットワークコンポーネントからジョブサービスプロキシへの印刷要求の有線通信時の手順の詳細を示すシーケンス図である。
【図７】図５におけるネットワークコンポーネントからジョブサービスプロキシへの印刷要求の無線通信時の手順の詳細を示すシーケンス図である。
【図８】図７における各手順と図４における各手順との関係を説明するためのシーケンス図である。
【図９】従来のラッパーの作用について説明するための図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施形態について図面を参照して説明する。
〈情報処理装置の構成〉
図１は、本発明の実施形態に係る情報処理装置のブロック図である。この情報処理装置１０は通信機能を有する画像形成装置であり、ネットワークＩ／Ｆ（インタフェース）１１、コントローラ部１２、エンジン部１３、Ｉ／Ｏ入出力回路１４、表示部（操作パネル）１５、補助記憶部（ＨＤＤ）１６、画像形成部１７、及びその他の機器群（給紙搬送部等）１８を備えている。
【００１６】
ネットワークＩ／Ｆ１１は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などの公衆回線及び無線回線などのネットワークを介して、情報処理装置１０とネットワークに接続される他の通信機器との間でデータをやり取りするためのインタフェースである。
【００１７】
コントローラ部１２は、コントローラ制御部であるＣＰＵ（Central Processing Unit）１２ａによって、情報処理装置１０が有する機能を実現するためのプログラムを実行し、情報処理装置１０の全体の動作を制御する。そのため、コントローラ部１２の主記憶部１２ｂは、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）を有しており、例えば、情報処理装置１０を制御するプログラムがＲＯＭに格納されている。そして、情報処理装置１０全体の動作を制御するプログラムがＲＡＭに展開（ロード）され、ＲＡＭに展開されたプログラムがＣＰＵ１２ａで実行される。
【００１８】
エンジン部１３は、エンジン制御部であるＣＰＵ１３ａによって、情報処理装置１０が有する画像形成機能を実現するための各部の制御を行う。そのため、エンジン部１３の主記憶部１３ｂは、ＲＯＭ及びＲＡＭを有しており、ＲＯＭに格納されたプログラムがＲＡＭに展開され、ＲＡＭに展開されたプログラムがＣＰＵ１３ａで実行される。
【００１９】
Ｉ／Ｏ入出力回路１４は、コントローラ部１２、エンジン部１３、及びこれらによって制御される各部との間でデータをやり取りするためのインタフェースである。表示部１５は、ＬＣＤ（Liquid Crystal Display）などのディスプレイを備え、ジョブに関する情報、情報処理装置１０の動作条件、及び動作状態などの各種情報をディスプレイに表示する。
【００２０】
補助記憶部１６は、ハードディスク（ＨＤＤ）であって、情報処理装置１０が取り扱う各種情報や拡張機能プログラム、基本ソフトであるＯＳなどが格納されている。画像形成部１７は、エンジン部１３のＣＰＵ１３ａによって制御され、コントローラ部１２で画像処理された印刷情報（印刷データ）から画像を形成し、給紙カセット部に収納された印刷用紙に印刷する。
【００２１】
その他の機器群１８は、各種サイズの印刷用紙を収納した給紙カセット部と、給紙カセット部に収納された印刷用紙を取り出して画像形成部１７へ搬送する給紙搬送部と、画像形成部１７によって印刷された後の印刷用紙を排紙トレイに排紙する排紙部と、これら各装置を駆動する駆動部などからなる。
【００２２】
〈ソフトウェア群〉
図２は、情報処理装置１０に実装されているソフトウェア群を示す図である。このソフトウェア群２０は補助記憶部１６により保持されている。このソフトウェア群２０はコントローラ部１２内のＣＰＵ１２ａが使用するプログラムである。
【００２３】
図示のように、ソフトウェア群２０は、第１のＯＳ２１、第２のＯＳのラッパー２２、ネットワークコンポーネント２３、ネットワークアプリケーション２４、及びコントローラシステム２５を備えている。ここでは、第１のＯＳはThread X（登録商標）であり、第２のＯＳはμITRONである。
【００２４】
ネットワークコンポーネント２３は、ＴＣＰ（Transmission Control Protocol）スタック２３１、有線ドライバ２３２、無線ドライバ２３３からなる。ＴＣＰスタック２３１は、ネットワークＩ／Ｆ１１を介するＴＣＰ通信のプロトコルを実行するプログラムである。有線ドライバ２３２は、ネットワークＩ／Ｆ１１を介する有線通信を実行するプログラムであり、無線ドライバ２３３は、ネットワークＩ／Ｆ１１を介する無線通信を実行するプログラムである。
【００２５】
ネットワークアプリケーション２４は、ジョブサービスプロキシ、及びネットワークコンポーネント制御部を備えている。コントローラシステムは、印刷アプリケーションなどのアプリケーションを含む。
【００２６】
以上のソフトウェア群２０において、ＴＣＰスタック２３１及び有線ドライバ２３２は、第２のＯＳ上で動作していたものを第１のＯＳ２１上で動作するようにポーティング（移植）したものである。また、無線ドライバ２３３及びネットワークアプリケーション２４は、第２のＯＳ上で動作していたものを、第２のＯＳのラッパー２２を介して第１のＯＳ２１上で動作するようにしたものである。また、コントローラシステム２５は第１のＯＳ２１上で動作していたものをそのまま流用したものである。
【００２７】
つまり、ＴＣＰスタック２３１及び有線ドライバ２３２は、第２のＯＳを含む第２のプラットフォームから、第１のＯＳを含む第１のプラットフォームへ移植したものである。即ち、従来の第１の方法による対応である。また、無線ドライバ２３３及びネットワークアプリケーション２４は、第２のプラットフォームから、第２のＯＳのＡＰＩと第１のＯＳのＡＰＩとの差異を吸収する第２のＯＳのラッパーを介して第１のプラットフォームへ移植したものである。即ち、従来の第２の方法による対応である。
【００２８】
〈タスクとシステムコール〉
図３は、情報処理装置１０におけるタスクとシステムコールとの関係を示す図である。システムコールはＡＰＩの一種である。この図において、破線の左側に配置されている第１のタスク１０１は、第１のＯＳ２１のシステムコール１１０により生成されたタスクである。また、破線の右側に配置されている第２のタスク１０２は、第２のＯＳのラッパー２２のシステムコール１２０により生成されたタスクである。
【００２９】
ここで、第１のタスク１０１は第１のＯＳ２１のシステムコール１１０を呼び出すことができるが、第２のＯＳのラッパー２２のシステムコール１２０を呼び出すことはできない。その理由は、第１のタスク１０１には、第１のＯＳ２１のシステムコール１１０の管理情報が付属しているが、第２のＯＳのラッパー２２のシステムコール１２０の管理情報が付属していないからである。
【００３０】
ここで、第２のＯＳのラッパー２２のシステムコール１２０の管理情報としては、(i)システムコール１２０でタスクを生成した際に振られるタスクＩＤ（タスクの識別番号）、(ii)システムコール１２０で生成したタスクの状態（実行状態/実行可能状態/待ち状態等）、(iii)第１のＯＳ２１の情報（第１のＯＳ２１上で動作するためのメモリの番地・サイズ等）があり、第１のタスク１０１は(i)、(ii)の情報を持っていない。
【００３１】
この図を図２と対応させると以下のようになる。有線ドライバ２３２及びＴＣＰスタック２３１は、ともに第１のＯＳ２１上で動作するので、有線ドライバ２３２を使用するタスク及びＴＣＰスタック２３１を使用するタスクは、ともに第１のタスク１０１となる。また、無線ドライバ２３３を使用するタスクは第２のタスク１０２となる。
【００３２】
このため、ＴＣＰスタック２３１を使用するタスクが有線ドライバ２３２を使用するタスクとの間で同期処理などのタスク間通信を行うためには、第１のＯＳ２１のシステムコール１１０を呼び出せばよいので、実行可能である。
【００３３】
しかし、ＴＣＰスタック２３１を使用するタスクが無線ドライバ２３３を使用するタスクとの間でタスク間通信を行うためには、第２のＯＳのラッパー２２のシステムコール１２０を呼び出すことが必要となるため、実行不能である。
【００３４】
〈仲介タスクの作用〉
そこで、情報処理装置１０では、仲介タスクにより、上記の呼び出しを可能とした。仲介タスクは、第２のＯＳのラッパー２２のシステムコール１２０で生成されたものであり、第２のＯＳのラッパー２２のシステムコール１２０の管理情報に加えて、第１のＯＳ２１のシステムコール１１０の管理情報が付属している。このため、仲介タスクは、第２のＯＳのラッパー２２のシステムコール１２０だけでなく第１のＯＳ２１のシステムコール１１０をも呼び出すことができる。図４は、情報処理装置１０における仲介タスクの作用を説明するための図である。
【００３５】
第１のタスク１０１は、第２のタスク１０２へメッセージを送信するために、第１のＯＳ２１のシステムコール１１０を呼び出して使用し、仲介タスク１０３に対して、第２のタスク１０２へメッセージを送信することのリクエストを送信する（ステップＳ１）。
【００３６】
仲介タスク１０３は、第１のＯＳ２１のシステムコール１１０を使用してリクエストを受信する（ステップＳ２）。次に、仲介タスク１０３は、受信したリクエストに応じて、第２のＯＳのラッパー２２のシステムコール１２０を呼び出して使用し、第２のタスク１０２に対して、第１のタスク１０１からのメッセージを送信する（ステップＳ３）。
【００３７】
第２のタスク１０２は、第２のＯＳのラッパー２２のシステムコール１２０を使用して、第１のタスク１０１からのメッセージを受信し（ステップＳ４）、その結果を仲介タスク１０３に送信する（ステップＳ５）。仲介タスク１０３は、第２のＯＳのラッパー２２のシステムコール１２０を使用して、第２のタスク１０２からの結果を受信する（ステップＳ６）。
【００３８】
次に、仲介タスク１０３は、第１のＯＳ２１のシステムコール１１０を呼び出して使用し、第２のタスク１０２からの結果を第１のタスク１０１に送信する（ステップＳ７）。第１のタスク１０１は、第１のＯＳ２１のシステムコール１１０を使用して、その結果を受信する（ステップＳ８）。
【００３９】
このように、システムコール１１０及びシステムコール１２０の呼び出しが可能な仲介タスク１０３を設け、仲介タスク１０３は、第１のタスク１０１と通信を行うときは、システムコール１１０を使用し、第２のタスク１０２と通信を行うときは、システムコール１２０を使用するように構成したことで、第１のタスク１０１は、システムコール１１０の呼び出しと、システムコール１２０の呼び出しとを同一のものとして扱うことができる。つまり、ＯＳ特有のシステムコールを他のＯＳにより作成されたタスクが意識することなく呼び出せるので、ＯＳの異なる環境で作成されたプログラムの変更差分を少なくすることができる。
【００４０】
〈印刷データ受信時の動作〉
図５は、情報処理装置１０が印刷データを受信した時のソフトウェア群２０の動作を示すシーケンス図である。
【００４１】
ネットワークコンポーネント２３（有線ドライバ２３２又は無線ドライバ２３３）は、印刷データを受信すると、ネットワークコンポーネント制御部２４１に対して、印刷セッションのオープンを要求する（ステップＳ１１）。
【００４２】
ネットワークコンポーネント制御部２４１は、ジョブサービスプロキシ２４２に対して、“印刷要求”を送信する（ステップＳ１２）。ジョブサービスプロキシ２４２は、コントローラシステム２５に対して、“印刷要求”を送信する（ステップＳ１３）。
【００４３】
コントローラシステム２５は、ジョブサービスプロキシ２４２に対して、“印刷用セッションＩＤ”を通知する（ステップＳ１４）。この“印刷用セッションＩＤ”は、ジョブサービスプロキシ２４２からネットワークコンポーネント制御部２４１を介して、ネットワークコンポーネント２３に通知される（ステップＳ１５、Ｓ１６）。
【００４４】
ネットワークコンポーネント２３は、ジョブサービスプロキシ２４２に対して、“印刷要求”を送信し（ステップＳ２１）、ジョブサービスプロキシ２４２は、コントローラシステム２５に対して、“印刷要求”を送信する（ステップＳ２２）。コントローラシステム２５は、ジョブサービスプロキシ２４２に対して、“印刷データ受信結果”を送信する（ステップＳ２３）。この“印刷データ受信結果”は、ジョブサービスプロキシ２４２からネットワークコンポーネント２３に送信される（ステップＳ２４）。印刷データがなくなるまで、ステップＳ２１〜Ｓ２４を繰り返す。
【００４５】
ネットワークコンポーネント２３は、印刷データがなくなったら、ネットワークコンポーネント制御部２４１に対して、印刷セッションのクローズを要求する（ステップＳ３１）。ネットワークコンポーネント制御部２４１は、ジョブサービスプロキシ２４２に対して、“印刷要求（印刷終了）”を送信する（ステップＳ３２）。ジョブサービスプロキシ２４２は、コントローラシステム２５に対して、“印刷要求（印刷終了）”を送信する（ステップＳ３３）。
【００４６】
コントローラシステム２５は、ジョブサービスプロキシ２４２に対して、“印刷終了”を通知する（ステップＳ３４）。この“印刷終了”の通知は、ジョブサービスプロキシ２４２からネットワークコンポーネント制御部２４１を介して、ネットワークコンポーネント２３に伝達される（ステップＳ３５、Ｓ３６）。
【００４７】
〈有線通信時の印刷要求手順の詳細〉
図６は、図５におけるネットワークコンポーネントからジョブサービスプロキシへの印刷要求の有線通信時の手順の詳細を示すシーケンス図である。この手順は、有線ドライバ２３２が印刷データを検知している間、繰り返し実行される。
【００４８】
ＴＣＰスタック２３１を使用するタスクであるｓＸパケットタスク２３１ａは、有線ドライバ２３２に対して予め関数を登録しておき、有線ドライバ２３２は、印刷データを受信したとき、その関数を呼び出すことで、印刷データを受信したことをｓＸパケットタスク２３１ａに通知する。ｓＸパケットタスク２３１ａは、有線ドライバ２３２に対して、“dev_recv( )”を送信する（ステップＳ４１）。“dev_recv( )”は、有線ドライバ２３２に対して印刷データの送信を要求する関数（システムコール）であり、印刷データのパケットを格納する領域の先頭アドレスが引数となっている。
【００４９】
有線ドライバ２３２は、“dev_recv( )”に対する応答として印刷データをｓＸパケットタスク２３１ａに送信する（ステップＳ４２）。ｓＸパケットタスク２３１ａは、受信した印刷データを各プロトコル別の受信キューに格納する（ステップＳ４３）。ここで、プロトコルには、ＬＰＤプロトコル（印刷プロトコル）、ＨＴＴＰＤ（Ｗｅｂサーバのプロトコル）などがある。
【００５０】
次に、ｓＸパケットタスク２３１ａは、ＴＣＰスタック２３１を使用するタスクであるｓＸＩＰ＿ＲＥＣＶ２３１ｂに印刷データを渡す（ステップＳ４４）。ｓＸＩＰ＿ＲＥＣＶ２３１ｂは、ジョブサービスプロキシ２４２に印刷データを渡す（ステップＳ４５）。
【００５１】
以上説明した有線通信時の印刷要求手順では、有線ドライバ２３２を使用するタスク、ｓＸパケットタスク２３１ａ、ｓＸＩＰ＿ＲＥＣＶ２３１ｂは、全て第１のＯＳ２１のシステムコール１１０で生成されたタスク（第１のタスク）である。そのため、ｓＸパケットタスク２３１ａは、第１のＯＳ２１のシステムコール１１０を呼び出すことで、有線ドライバ２３２を使用するタスクとの間で同期処理を行うことができる。なお、ｓＸパケットタスク２３１ａとｓＸＩＰ＿ＲＥＣＶ２３１ｂとの間の通信（ステップＳ４４）は、同期処理ではないので、システムコールの呼び出しは行わない。
【００５２】
〈無線通信時の印刷要求手順の詳細〉
図７は、図５におけるネットワークコンポーネントからジョブサービスプロキシへの印刷要求の無線通信時の手順の詳細を示すシーケンス図である。この手順は、無線ドライバ２３３が印刷データを検知している間、繰り返し実行される。
【００５３】
ＴＣＰスタック２３１（ｓＸパケットタスク２３１ａ）は、仲介タスク１０３に対して、“データ受信要求”を送信する（ステップＳ５１）。仲介タスク１０３は、“データ受信要求”の受信に基づいて、無線ドライバ２３３に対し、“dev_recv( )”を送信する（ステップＳ５２）。
【００５４】
無線ドライバ２３３は、“dev_recv( )”に対する応答として印刷データを仲介タスク１０３に送信する（ステップＳ５３）。仲介タスク１０３は、印刷データを受信し、“データ受信要求”に対する応答として、ＴＣＰスタック２３１に送信する（ステップＳ５４）。
【００５５】
ＴＣＰスタック２３１は、受信した印刷データを各プロトコル別の受信キューに格納し（ステップＳ５５）、ネットワークアプリケーション２４に印刷データを渡す（ステップＳ５６）。
【００５６】
以上説明した無線通信時の印刷要求手順では、ｓＸパケットタスク２３１ａは第１のＯＳ２１のシステムコール１１０で生成されたタスク（第１のタスク）であるのに対し、無線ドライバ２３３を使用するタスクは第２のＯＳのラッパー２２のシステムコール１２０で生成されたタスク（第２のタスク）である。そこで、第１のＯＳ２１のシステムコール１１０及び第２のＯＳのラッパー２２のシステムコール１２０の呼び出しが可能な仲介タスク１０３が、ｓＸパケットタスク２３１ａと無線ドライバ２３３を使用するタスクとの間の同期処理を仲介する。
【００５７】
〈無線通信時の印刷要求手順におけるシステムコールの呼び出し〉
図８は、図７における各手順と図４における各手順との関係を説明するためのシーケンス図である。
【００５８】
図示のように、ＴＣＰスタック２３１と仲介タスク１０３との間のデータ受信要求の通信手順（ステップＳ５１）では、第１のＯＳ２１のシステムコール１１０が使用される（ステップＳ１，Ｓ２）。また、仲介タスク１０３と無線ドライバ２３３との間の“dev_recv( )”の通信手順（ステップＳ５２）では、第２のＯＳのラッパー２２のシステムコール１２０が使用される（ステップＳ３，Ｓ４）。また、無線ドライバ２３３と仲介タスク１０３との間の印刷データの通信手順（ステップＳ５３）では、第２のＯＳのラッパー２２のシステムコール１２０が使用される（ステップＳ５，Ｓ６）。また、仲介タスク１０３とＴＣＰスタック２３１との間の印刷データの通信手順（ステップＳ５４）では、第１のＯＳ２１のシステムコール１１０が使用される（ステップＳ７，Ｓ８）。
【００５９】
なお、有線通信時の手順は、この図における「無線ドライバ２３３」を「有線ドライバ２３２」で置き換え、「仲介タスク１０３」及び「第２のＯＳのラッパー２２のシステムコール１２０」を除去したものとなる。即ち、「ＴＣＰスタック２３１」⇔「第１のＯＳ２１のシステムコール１１０」⇔「有線ドライバ２３２」の手順となる。
【００６０】
この図のステップＳ５１〜Ｓ５４（Ｓ１〜Ｓ８）のような情報の受け渡しのときに呼び出されるシステムコールについて説明する。
情報を受け渡す場合、一方のタスクが「情報待ち」のシステムコールを呼び出し、他方のタスクが「情報送信」のシステムコールを呼び出す。「情報待ち」のシステムコールが呼ばれた場合、タスクを生成した際に振られる“タスクＩＤ”をシステムコール側で解釈し、そのタスクが情報を待っているということを記憶する。同時に何らかの情報が渡ってくるまで、システムコールを呼び出したタスクの処理を止める。その後「情報送信」のシステムコールが呼ばれると、システムコール側で「情報待ち」をしているタスクに対して、情報の送信を行う。
【００６１】
しかし、タスクを生成した際に振られる“タスクＩＤ”を持たないタスクが「情報待ち」のシステムコール呼び出し時には、どのタスクが待ち状態になろうとしているかシステムコール側で解釈できない。このため、即座に異常と判断し、タスクの処理を止めることができない。また、タスクの処理を止めないため、「情報待ち」のシステムコールを呼び出したタスクが情報を受け取ることもできなくなる。
【００６２】
このように、本発明の実施形態に係る情報処理装置１０によれば、第１のＯＳ２１のシステムコール１１０及び第２のＯＳのラッパー２２のシステムコール１２０の呼び出しが可能な仲介タスク１０３を設けることで、第１のタスク１０１は、第１のＯＳ２１のシステムコール１１０の呼び出しと、第２のＯＳのラッパー２２のシステムコール１２０の呼び出しとを同一のものとして扱うことができる。これにより、第１のタスク１０１は、第２のＯＳのラッパー２２のシステムコール１２０で生成されたタスク（第２のタスク１０２）に対して、同期処理のためのメッセージを送信することができる。
【符号の説明】
【００６３】
１０…情報処理装置、２１…第１のＯＳ、２２…第２のＯＳのラッパー、１０１…第１のタスク、１０２…第２のタスク、１０３…仲介タスク、１１０…第１のＯＳのシステムコール、１２０…第２のＯＳのラッパーのシステムコール。
【先行技術文献】
【特許文献】
【００６４】
【特許文献１】特開２００４−２４６６９０号公報
【図１】
2015148836.tif 000003
【図２】
2015148836.tif 000004
【図３】
2015148836.tif 000005
【図４】
2015148836.tif 000006
【図５】
2015148836.tif 000007
【図６】
2015148836.tif 000008
【図７】
2015148836.tif 000009
【図８】
2015148836.tif 000010
【図９】
2015148836.tif 000011