NuDCLその8

FireWireのアイソクロナス転送でデータをやりとりするためのMacOS XのI/O Kitによるメカニズムである2種類のDCLの違いについて一通りまとめた。昨日からは、SDK26にあるUnversalReceiveTestアプリのソースを見てどのように使われているかを見ている。今日はアイソクロナス転送を行うC++クラスであるUniversalReceiverのコンストラクタ。

3.2  UniversalReceiverクラス

ここまでは全然簡単だった。次に、UnversalReceiverクラスそのものを見る。アイソクロナス転送でデータを受け取るためのクラスで、かなり大きな、というかベタに一つのクラスとして書かれたものでインスタンス変数が大量にあって読みにくい。一つ一つ見ていくしかない。まずコンストラクタを見る。

3.3  コンストラクタ

コンストラクタはたくさんの引数を持っている。

UniversalReceiver(
      StringLogger *stringLogger = nil,
      IOFireWireLibNubRef nubInterface = nil,
      unsigned int cyclesPerSegment = kCyclesPerUniversalReceiveSegment,
      unsigned int numSegments = kNumUniversalReceiveSegments,
      unsigned int cycleBufferSize = kUniversalReceiverDefaultBufferSize,
      bool doIRMAllocations = false,
      unsigned int irmAllocationPacketLen = kUniversalReceiverDefaultBufferSize);

stringLoggerというのはエラーなどのメッセージ出力用の専用のクラス。nubInterfaceはFireWireデバイスインターフェイスをもらう。

また、受信データが

• cycle
• segment

という入れ子構造を持っているとみなしているらしい。cycleというのはバスサイクルのことなのか、関係ないのかよくわからない。segmentというのが何を指しているのかわからない。1394の詳細仕様をみればあるのかもしれない。少なくとも公開されている「手引書」にはハード的なバスの枝を表す言葉としてしか出てこない。

まあ、numSegments個のsegmentがあってひとつのsegmentはcyclesPerSegment個のcycleがあって、そのcycleがcycleBufferSizeバイトのバッファを持っているということらしい。コンストラクタの中では２重ループになっている。

古いDCLの時もよくわからなかったIRMというパラメータも引数としてもらってくるようになっている。IRMというのはIsochronous Resource Managerのことなんだろうけどこのフラグをセットすることが何をすることなのかよくわからない。とりあえずおいといて先に進む。

コンストラクタではたくさんの自動変数を初期化したあと、receiveSegmentInfoという構造体の配列を作っている。

	receiveSegmentInfo = new UniversalReceiveSegment[isochSegments];

isochSegmentsは引数として渡されてきたsegmentの数numSegmentsそのまま。UniversalReceiveSegmentという構造体はヘッダに

struct UniversalReceiveSegment
{
    NuDCLReceivePacketRef segmentStartDCL;
    NuDCLReceivePacketRef segmentEndDCL;
};

となっていて、DCLコマンドふたつをさすようになっている。

そのあと、transportControlMutexとnoDataTimerMutexというふたつのpthreadのミューテクスロックを作ってからdclCommandPoolSizeというインスタンス変数を設定してコンストラクタは終わる。dclCommandPoolSizeはNuDCLでは使わない。