BonDriver共有ツール総合 その2

1 ：名無しさん＠編集中：2015/04/07(火) 20:25:07.03 ID:n6IDd8Gi.net

BonDriver共有ツール総合

※前スレ
http://peace.2ch.net/test/read.cgi/avi/1366339738/

301 ：名無しさん＠編集中：2015/09/16(水) 09:19:05.96 ID:BfRuKofg.net

>>300
そのソースをうｐした者です。
S_FALSEだったらすでにCoInitializeされてるはずであり、2重にCoInitializeは行われていないということなのでそのままにしておくという考えです。
ですから、S_FALSEだった時にはCoUnInitializeも行わないようになっています。
スレッドIDを記憶している理由は、CloseTunerがOpenTunerと別スレッドで呼ばれた場合に
自分以外が行ったCoInitializeを間違ってCoUnInitializeしてしまわないようにしているだけです。
どちらにせよCoUnInitializeする術がないので。

私は、BonDriver側の責任でCoInitializeを行うべきだと思っています。
BonDriverでCOMを使用するかどうかはBonDriver側の都合なので。
今考えているところで一番良いやり方は、BonDriver側でAppとは独立した別スレッドを作成し、
そのスレッドでCoInitialize/CoUnInitializeを含めたすべてのCOM処理を行うのが最善ではないかなと思っています。
近いうちにリンク先にあったBonDriverでそれをやってみたいと思います。

302 ：300：2015/09/16(水) 16:35:23.46 ID:d1QHFDlx.net

>>301
そう思いがちなのですが違うのです。
https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms695279(v=vs.85).aspx

each successful call to CoInitialize or CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize.

実は、S_FALSEのSはsuccessもしくはsucceedのSで、S_FALSEでもCoInitializeされてしまうのです。従って、CoUnInitializeが必要になります。

なので、実装として正しいのはS_FALSEの場合はすぐに CoUnInitializeしてやることだと思ってます。

もちろん呼び出しによらず別スレッドで完結できればそれに越したことはないと思います。

303 ：300：2015/09/16(水) 18:08:43.78 ID:JWzbiEwR.net

>301
可能でしたらCoInitializeExのスレッドモデル教えて頂きたいことがあります。
殆どのBonDriverと同様COINIT_APARTMENTTHREADEDを指定しているようですが、
COINIT_MULTITHREADEDにしない何か理由等ありますでしょうか。

というのも、BonDriver自体は当然ウインドウに絡む処理はありませんし、
TVTestの様に仮に呼び出し元のアプリケーションでウインドウに絡む処理があって、
かつ、同一のスレッドでCOMを使う場合でもアプリケーション側で初期化を行うはずなので
COINIT_MULTITHREADEDで新たに初期化しようとしてもRPC_E_CHANGED_MODEが
返ってくるだけです。

EDCBのようにBonDriver絡みでそもそもCOMを使わない場合はそれこそスレッドモデルは
なんでもいいはず。

さらに、アプリケーション側で、BonDriver側のメモリにアクセスすのはGetTsStream、PurgeTsStreamで、
これらの処理は当然CriticalSectionにしているはずなので、スレッドセーフといえる。

というわけでCOINIT_MULTITHREADEDで問題ないと思っています。
何か見当違いをしているかもしれませんが、その際はご指摘いただけたらありがたいです。

304 ：名無しさん＠編集中：2015/09/16(水) 18:11:52.70 ID:JWzbiEwR.net

もっともCOINIT_MULTITHREADEDにしたい理由は
「若干のパフォーマンスアップがある、かも」くらいなので、
予期せぬ破綻が起きないために、とりあえずCOINIT_APARTMENTTHREADEDにする、
というのもアリだと思います。

305 ： ◆SALrG1ld3mTc ：2015/09/16(水) 20:06:22.11 ID:53Si47U2.net

>>296
BonDriver_PX_W3PE_S0.dllがBonDriver_HDUSの改造でつくられていると言うのは多分その通りで、
ttp://www2.wazoku.net/2sen/hdusup/source/up0233.zip
のソースで言うと、DShowMain.cppの748行目に相当する部分で例の初期化処理を呼んでるようですね

C++なので仮想関数呼び出しになってて、ioctl()に相当するコードが具体的にどうなっているのか
テキトーにバイナリを眺めてるだけでは特定がめんどくさいのですが、PX-W3PEの実機を持ってる方なら
BonDriver_PX_W3PE_S0.dllをロード -> CreateBonDriver() -> OpenTuner()とやって、OpenTuner()の
内部をデバッガで追って行けば、結構簡単に特定できるんじゃないかなと思います

dllのロードアドレス+1040c辺りからが問題の処理なので、ここにブレークポイント置いて
動かしてみるのが手っ取り早いかと…

306 ： ◆SALrG1ld3mTc ：2015/09/16(水) 20:11:58.58 ID:53Si47U2.net

>>301
> S_FALSE

>>302さんの書かれてる通りですが、MSのAPIにはたまーにこの手の罠がありますね…

> 私は、BonDriver側の責任でCoInitializeを行うべきだと思っています。
> BonDriverでCOMを使用するかどうかはBonDriver側の都合なので。

まあ行うにせよ行わないにせよ、ライブラリの使用方法に制限をかける形になるのは同じで、
単にライブラリが、
---
a. 使用するには呼び出し側での初期化が必要ですが、それを守る限りは自由なAPI呼び出しが可能です
b. 対になるAPIを異なるスレッドから呼び出す事はサポートしませんが、特に前準備無しでも使用可能です
---
のどちらの立場をとるのかと言う話なので、ライブラリ作者の好みの問題ではありますね
＃個人的にはa.の方が好きですがヽ(;´ー`)ノ

ただ、そのライブラリのドキュメントやソースが無い場合には、a.のパターンでは最初から動かず、b.のパターンでは
アプリのつくりによって動いたり動かなかったり、と言う感じになるので、どちらがマシかと言う話になります
この場合は、ライブラリユーザ(アプリ作者)としてはa.の形であった方が助かるんじゃないかなーと思ってます…

307 ： ◆SALrG1ld3mTc ：2015/09/16(水) 20:15:17.65 ID:53Si47U2.net

> 今考えているところで一番良いやり方は、BonDriver側でAppとは独立した別スレッドを作成し、
> そのスレッドでCoInitialize/CoUnInitializeを含めたすべてのCOM処理を行うのが最善ではないかなと思っています。

ですね、非常に有効だと思いますヽ(´ー`)ノ
若干トリッキーではありますが、外部に公開しているAPIの内COMが絡むものは、呼び出されたらイベントをトリガして
実際の処理はそれを受けたワーカースレッドでやり、処理が終わればそれをイベントのトリガ元に通知すると言う形に
すれば、ライブラリ内でCOMの初期化/終了処理を完結できるので、APIの呼び出し方に制限はかからずアプリ側での
初期化/終了処理も不要にできますね
＃ちなみに、今のBonDriver_Proxyも(COMを使う目的ではありませんが)似たような実装になっています

308 ：名無しさん＠編集中：2015/09/17(木) 01:38:04.41 ID:UxTbU+TO.net

>>303-304
COINIT_MULTITHREADEDにするって事はCOM呼びだしのスレッド同期処理は全部自前でやるって事だけど
>>301で書いてるみたいに自前でスレッド起こして無い以上、どっちみちスレッド同期処理とか不可能だよね。

GetTsStream()やPurgeTsStream()がCriticalSectionでガードされてた所で
COMを呼び出すスレッドが同一スレッドである保証なんてどこにもないよ。
ガードされてても別スレッドからの呼出なら、どこかでCoInitialize()しなきゃいけない。

どっちみち>>301の方法以外では別スレッドからの呼びだしなんて解消出来ない。

COMのスレッド周りに関する話は
ttp://www.kekyo.net/2012/06/16/80
ttp://www.kekyo.net/2013/07/22/382
この辺が参考になるよ
COMのアパートメント(1)〜(6)は全部読んだ方がいい。

309 ：301：2015/09/17(木) 10:01:23.53 ID:HpsXGkNf.net

>>302
うわ、完全に勘違いしてました。
確かにそう書いてありますね。
S_FALSEの場合はすぐに CoUnInitializeしてやるのが正解なんですね。
ちなみにRPC_E_CHANGED_MODEが返ってきた場合はどう対処するのが正解なんでしょうか？
（例のソースではこれが返ってきたときのことは想定していません）

COINIT_MULTITHREADEDについては、難しすぎてよく理解できてないんですが、
>>308のとおりBonDriverという立場では使用できないと思ってます。

310 ：名無しさん＠編集中：2015/09/18(金) 00:33:12.57 ID:9PcEUns2.net

>>305 ioctl()に相当するコードについての解析記録です。

BonDriver_PX_W3U3_T0.dllの中を解析していくために、BonDriverExの直下にBonDriver_PX_W3U3_T0.dllを組み込む設定にし、BonDriverExを起動。WinDBGをアタッチ。TVTestを起動した。
BonDriverExのm_pIBon->OpenTuner()で一時停止。そこからトントントンと数ステップでdllの中にin。そこからステップ実行で進んでみるがシンボルがある所以外は、何の処理なのか、
今どこにいるのかもわからない。そもそもこれを追っていける解析能力が自分にはない。そこで自分にも出来る別のアプローチをとることにした。

まずはDeviceIoControlがシステム上のどこにあるのか突き止めるため、デバイスドライバをオープンして閉じるだけの短いプログラムを作成。
追って行くとKERNELBASE.dll+オフセットAA680に DeviceIoControlが見つかる。
2ステップ程進んだ　call KERNELBASE!GetAdjustObjectAttributesForPrivateNamespaceRoutine+0x18でスタック上に値を入れて戻ってきた。
更に2ステップ程進んだところで、C++上のDeviceIoControl(）で64bit設定したマイナーファンクションコードが16bitになってcxレジスタ上に0x8d81が入っていた。これがデバイスドライバに送られる模様。
この時点での呼び出し順は　プロセス→kernel32.dllのDeviceIoControl→KERNELBASE.dllのDeviceIoControlであった。

次にBonDriver_PX_W3U3_T0.dllからどうDeviceIoControlが呼ばれるのか調べる為にKERNELBASE.dll.DeviceIoControlに網を張ることにする。
WinDBGに　bp KERNELBASE!DeviceIoControl+0xF "j cx==0x8d81'';'g'"　とcxレジスタが0x8d81の時停止するように入れてみた。
んー停止せずTVTestが映ってしまった。　ということは�@DeviceIoControlが利用されており引数のマイナーファンクションコードがLinuxのドライバと違う、
�A別プロセスからドライバに読書されたか、�BWindows上の他のシステム関数から読書されたことになりそうだ。