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も受け取れる仕様にする必要があるか…

だんだん面倒な方向に…

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

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