\chapter{GearsOSの評価}
当研究は純粋なGearsOSを用いて実装されるプロジェクトとしては初めてのものとなっている。
本章ではファイルシステムの構築を通したGearsOSの評価を行う。



\section{トランスコンパイラによるstubCodeGearの誤生成}
GearsOSの最大の特徴としてノーマルレベルとメタレベルのプログラムを分離して記述をする必要があるという点が存在する。
メタレベルのプログラムは現状、Perlスクリプトを用いたトランスコンパイラにより自動生成されている形となっている。
トランスコンパイラにより生成されるメタレベルなプログラムの中で最も重要な部分として、DataGearの受け渡しを担当するstubCodeGearの生成がある。
本研究にて行われたGearsOSによるプログラムの記述の上で最も目立った問題点として、stubCodeGearの自動生成部分の仕様とバグが挙げられる。

別のInterfaceを継承したCodeGearからDataGearの受け取りたい場合に、自動生成されたstubCodeGearにバグが生じるという問題点がある。

ソースコード\ref{src:spro}にQueueからDataGearを受け渡しているstubCodeGearとその遷移前と遷移先のCodeGearを示す。
このプログラムではTask2にてlocalDGMQueueに対してCodeGear:takeに遷移、Queueのtake処理によって取り出したFileString型のstringを
Task3\texttt{\_}stubにて呼び出し、Task3へ引き渡している。
12行目ではGearefコマンドにてTQueue構造体の中の変数dataをFileString型のstringに格納している。
Gearef(context, TQueue)\texttt{->}dataには遷移前のCodeGearにて、take操作でQueueから取り出されたデータが格納されている。
このプログラムは正常に動作するが、問題点としてTask3\texttt{\_}stubは自動生成が行われたものでなく、手動で記述されていることが挙げられる。

ソースコード\ref{src:serro}にプログラマが記述したものではなく、トランスコンパイラにより自動生成されたエラーのあるTask3のstubCodeGearを示す。
この出力されたstubCodeGearの場合、実際にプログラムが実行された場合、Segmentation Faultを起こしてプログラムが終了してしまう。
string変数に格納したい、Queueから取り出されたデータの保管場所をstubCodeGearがうまく指定できていないためである。
これはFileString構造体はGearsOS内でInterfaceとして見なされており、
トランスコンパイラは変数の型を見てGearefコマンドの指定先をContextの保管場所としているために発生しているミスコードとなる。
実際にQueueから取り出されたデータが保存さている場所への参照はGearef(context, TQueue)\texttt{->}dataであるためこれを指定するのが正しい。

\lstinputlisting[label=src:spro, caption=takeCodeGearから遷移されるstubCodeGear]{src/StubProblem.cbc}

\lstinputlisting[label=src:serro, caption=自動生成にて出力されたTask3のstubCodeGear]{src/ErrorStub.cbc}

結論としてトランスコンパイラによる自動生成されたstubCodeGearは、別Interface上のCodeGearからDataGearを継承する場合、
どのInterfaceからDataGearを呼び出せばいいか判断ができないことが分かった。
この問題はstubCodeGearをプログラマが記述することにより解決できるが、
GearsOSの理想はプログラマが特別な意図を持たない限りはstubCodeGearは記述の必要がないことが望ましい。
加えて、CodeGearの処理が同一であっても、遷移前CodeGearが継承しているInterfaceが異っている場合、複数のCodeGearを記述しなくてはならない。

この問題を解決する案として、ContextはstubCodeGearに参照される際に、遷移前のCodeGearが継承しているInterfaceをなんらかの変数などに記憶させるといったことが考えられる。
DataGearは基本的に遷移する直前のCodeGearから引き継ぐ場合が多いため、直前のCodeGearのInterfaceへのGearefコマンドが行える形にすることが望ましい。

\section{par goto構文のバグ}
GearsFileSystemのAPI開発の上でpar goto構文を使った並列処理の利用を試みた。
しかし、par goto構文から自動生成されるメタレベルなコード出力の誤りやTaskの終了を示す\texttt{\_\_}exitが機能しないといった問題が発生した。
これらの問題はGearsOSの記述方法に統制が取られていないことが原因として挙げられる。

ソースコード\ref{src:mainDist}にpar goto構文を用いているCodeGearを示す。
加えてソースコード\ref{src:misspar}にソースコード\ref{src:mainDist}をトランスコンパイルした.cプログラムを示す。

この問題点の一つとしてTaskの終了を示すCodeGearである\texttt{\_\_}exitが機能しないという問題がある。
ソースコード\ref{src:mainDist}の4,5行目では本体par gotoにてTask:countUp\texttt{\_}code>eNumが終了次第、
Taskを処理したWorkerを解放せるための\texttt{\_\_}exitをnext\texttt{\_}codeとして指定したい。
しかし、下記のコードではトランスコンパイルの時点でエラーを起こし、プログラムのコンパイルが行えない。

6行目は別の並列プログラムtwiceでのpar gotoの記述である。異なる点として遷移先のCodeGearがなんらかのInterfaceの呼び出されたプログラムの中に記述されたものでなく、
そのCodeGear内で利用されるInterfaceをInputDataGearとして指定していることにある。
この記述の場合、\texttt{\_\_}exitは問題なく動作することができるが、GearsOSに実装されたQueueやTreeといった多くのプログラムはInterfaceを継承した上で実装されている。
そのため従来のプログラムをTaskとして利用することが難しくなっている。

加えてトランスコンパイラのバグも確認されている。
Interfaceを継承したプログラム内部へ記述されたCodeGearへのpar gotoはInputCodeGearが存在する場合、
ソースコード\ref{src:misspar}の15, 33行目のInterfaceのGET\texttt{\_}METAが生成されなくなってしまう。
\texttt{\_}METAは並列処理Task(CodeGear)のinputDataGearの待ち合わせを行う記述である。
ソースコード\ref{src:misspar}の場合、遷移先のInterfaceの待ち合わせが発生せず、
またプリミティブなinputDGとなるint型の0をDataGear名として待ち合わせしようとすることになってしまう。
そのため現状、Interface内CodeGearの分散処理は行うことができるが、InputDataGearがそのInterface自身とnext\texttt{\_}code以外のInputCodeGearが参照できない、
加えて\texttt{\_\_}exitが機能しないという問題が存在する。

\lstinputlisting[label=src:mainDist, caption=takeCodeGearから遷移されるstubCodeGear]{src/mainDist.cbc}

\newpage{}
\lstinputlisting[label=src:misspar, caption=自動生成にて出力されたTask3のstubCodeGear]{src/missingParGoto.cbc}