Orz日記 by Akio Morita

_ [SAD][EPICS]ca_pend_io & ca_pend_event

何かAPIが足りない気がする

• ca_getの完了を待つにはca_pend_ioが必要
• ca_pend_ioは、ca_pend_eventと異なりCAのbackgroud activityを処理しない
  • ca_pend_io中に届いたイベントの一部は喪失している & どこからのイベントがどれだけ失われたか分からない orz
• ca_pend_envetは、ca_pend_ioと異なり ca_getの完了待ちに使えない
• ca_pend_ioがECA_TIMEOUTするとca_get失敗が確定する
  • ca_getの完了をpollするAPIが無い

従って、ca_create_subscriptionしている状況で、ca_get + ca_pend_ioするとsubscription中のevent callbackの喪失が発生し得る&喪失したイベント発生元とイベント数が不明となる

結論…つかいものにならない

次善の策は？

やはり、AutoStart->FalseなCaMonitorからGetCBして、WaitValueするCaRead2互換実装作らないとだめか？ (callbackベースなら、ca_pend_eventで回せる)

多分、CaOpen済みのハンドルを想定するなら、chidを受け取るConstructorを設けるのが吉(Destruct/ClearChannel時にca_clear_channelしないこと) 多分、chid modifierも受け取れる仕様にする必要があるか…

だんだん面倒な方向に…

CaMonitorのValueCBについて

arg->dbr->statusに関しては、格納する領域が無い模様(捨てられている)

CaRead互換の出力をするのであれば、インスタンス変数の割り当て・Query methodの実装とValueCBへの格納コードの実装が必要

_ [SAD][EPICS]CaMonitorへstatus of valueの扱いを追加

従って、CaRead[{pvs...}]を以下の擬似コードでca_pend_ioを使わずに再実装できる

Module[{ca},
  ca = CaMonitor[{pvs...}, AutoStart->False,
    ConStatCommand:>With[{p = ca@PositionL[]},
      If[ca@ConnectedQ[p], ca@GetCB[p]]]];
  ca@WaitValue[EPICS$CaReadTimeout[]];
  MapThread[If[#1 === Undefined, $Failed, {##}]&,
    {ca@Value[], ca@Status[], ca@Severity, ca@Timestamp$[]}]];

• 接続ハンドラで、接続成立時にca_get_callbackを発行させ、WaitValueで更新を待つ構造
• CaMonitorインスタンスは、スコープ脱出時に破壊される
• transfer modifier対応させる場合は、vtypeのリストサポートが必要
• 接続済みchidを受けるConstructorが有ると良い

CaMonitorの改修作業

• vtypeのリストサポート
  • Countサポートと同様に、動作時の更新・参照をサポートするので有れば、オプション処理を変更する必要がある
• opened chidを受け取るConstructor
  • CaRead互換運用用途なので、Constructorサポートのみで足りるはず
  • ClearChannel時のca_clear_channelを制御するフラグを設ける
  • transfer modifer付きで受け取れると便利
    • modifierに基づき、vtype/countを自動的に初期化する
  • AutoStart/ConStatCommandの自動設定、GetCBの自動実行があっても良い？

_ [SAD][EPICS]ValueTypeオプション拡張

• PVリストに対して、個別の転送型指定が出きるようにList型のValueTypeオプションをサポート
• DefaultValueTypeオプションの導入
• ValueType[]・SetValueType[]メソッドによる動的参照・更新のサポート(Countオプションと同じ)
• ValueType[] = new, Count[] = new構文による動的更新サポート

次は、Constructor拡張？

_ [SAD][EPICS]CaRead2実装用CaMonitor`Constructor案

実装アイデア

• ClearChannel抑止オプション付きの状態で、専用のCreateChannelを呼び出す
• 引数列は、修飾付きchidのリストのみを処理する
  • 不正な引数列を受けたときの動作は未定義で良い
• count/vtypeに関しては、chidへの修飾子から自動設定
• AutoStartは、False
• 未接続のchidに関しては無視すると後処理が楽？
• GetCBの自動発行まで実装するか？
  • WaitValueするコードで駆動するので、そこまで行う自動化する必要は無い
• CaMonitorで登録済みのchidが渡されるケースで表面化する問題点
  • Fortran backendからCaMonitorへのcallbackが多重登録出来ない
  • ca_get_callbackと subscriptionからのcallbackをSADScript側で識別できない
  • subscriptionされていない場合は、callbackの登録を一時的に改変する余地が有る
    • Destructorで復元する必要が有る
    • Destruction前に、AutoStartや明示的なStart[]が呼び出されると面倒
  • CA接続を一時的に作る場合、失敗する可能性が残る

_ [SAD][EPICS]別解として、ca_get_callbackベースで実装したCaRead3の導入

実装アイデア

• dbr_time型のバッファへwrite backする専用callback routineを渡したca_get_callbackを発行する
• timestamp fieldを無効値で初期化して、更新検知する
• 全てのcallbackが完了するまで、ca_pend_event + pollingでblocking waitをかける

問題点は、timeoutまでに応答しないcallbackが有った場合に、ca_get_callbackをキャンセルするか、書き込み先の消失を指令するメモ領域が必要(メモ領域はcallback routine側で開放する必要がある)

callbackメモの内容

• 返り値のListオブジェクトの参照と内部インデックスで十分
• キャンセル時は、参照もしくはインデックスを無効値に書き換える
• 返り値のListオブジェクトは、Table[\$Failed, {n}]で初期化しておく
  • 更新検知は、タイプの変化で検出(ntfsymbol→ntflist)
• callback contextが、ca_pend_*に限定されれば、更新競合は避けられる
• ca_get_callbackは、callback routineと共にメモのアドレスを渡す
• メモはcallback routine側で開放可能とするために、heapから割り当てる必要あり
  • caの割り込み(callback) contextから安全に開放可能でなければならない
• 別案として、メモを管理する機構を設けて、安全なcontextから完了済みのメモを回収することも出来る
  • この場合、ca_get_callbackごとにメモを生成し、callback routineは処理完了マークをメモに記入する
  • GCは、安全なcontextから起動し、完了済みのメモを回収する
  • GCと割り当てが同時実行されないのであれば、簡単な単方向リスト構造で足りる
  • GC発動タイミング候補
    • CaRead3起動時、完了時