- PR -

アンマネージドとマネージドのスレッド対応

«前のページへ 1|2|3|4|5|6
投稿者投稿内容
Atata!!
常連さん
会議室デビュー日: 2007/05/22
投稿数: 20
投稿日時: 2007-07-02 14:05
引用:

@IT のプロファイルにはサイトの URL を登録してないんですね (^^;

これは全然気づいてませんでした。ご指摘ありがとうございます。
とりあえず、公開するようにしてみました。

# なぜ私は設定していなかったんだろうか・・・



引用:

#他ではこのような問題って起こってないんですかね？
#特に昔のものを単純に引きずっていってるようなものだと同じような問題にぶつかりそうに思うんですが
#あまりこういった話題を見かけないので、やっぱりちゃんとそこらへんを見越した設計されてるのかなぁ・・・


私も以前に遭遇したことがあります。
VC++6とVB6で構築されたシステムを段階的に .NET Framework に移行していくプロジェクトでしたが、
その時は費用対効果が悪いと言う結論に至り、フラグ変数を使って再入を防止するだけに留めました。


その時に修正案の1つとして出たのが、OCXでフリースレッドマーシャラを使用するという手法です。

フリースレッドマーシャラを使用する前提条件として以下の条件を満たす必要があります。
・使用するインターフェースがデュアルインターフェースもしくはカスタムインターフェースであること
・STA側で作成したCOMオブジェクト(特にCOMプロキシオブジェクト)を該当メソッド内で使用していないこと

その時は下側の条件を満たしておらず、条件を満たすための修正量が大きかったため採用されませんでした。
# 厳密には繰り返し修正していく過程で満たし続けることが難しいと判断されたことが原因ですが。


# 多分、この辺がCOMスレッド地獄の扉付近なんでしょうね。
# まぁ、一回扉を開けてみるのも面白いかと。
ちゃーはん
会議室デビュー日: 2007/06/25
投稿数: 13
投稿日時: 2007-07-02 14:59
渋木さん、ありがとうございます。

引用:

僕なら「全とっかえ」が引き受ける条件です

ですよね～
ずっと引きずっていこうとうのが無理があって、
小手先だけでは環境の変化(特に.NET)なんかの差異も吸収しきれなくなってるし、
もう限界なんじゃないかぁ、って個人的には思ってます。
なんか負の遺産を引き継いだって感じです。

#すいません、愚痴になっちゃいました。
#もっと建設的なことが書けないとダメですよね～
#まぁ、自分がヘッポコだってことが大きな原因なんですが・・・
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2007-07-02 15:08
引用:

# 多分、この辺がCOMスレッド地獄の扉付近なんでしょうね。


スレッド/アパートメント境界で嵌ると泣きますねぇ。
レガシ COM の場合 DLL 地獄もあるし。

.NET の登場でそんなものからは解放されるかと思いきや、今度はマネージ/アンマネージ境界とアプリケーションドメインの境界で泣くし。

さらに COM 連携なんかしだすとそれらの複合。。。
と、飯の種は尽きません (^^;

引用:

# まぁ、一回扉を開けてみるのも面白いかと。


まさに地獄の釜ｗ

引用:

ずっと引きずっていこうとうのが無理があって、
小手先だけでは環境の変化(特に.NET)なんかの差異も吸収しきれなくなってるし、
もう限界なんじゃないかぁ、って個人的には思ってます。
なんか負の遺産を引き継いだって感じです。


利子だけ払ってジャンプ、ではいつか破産しますからね。
どこかで踏ん張って元金を返済しなくちゃです。

引用:

#もっと建設的なことが書けないとダメですよね～
#まぁ、自分がヘッポコだってことが大きな原因なんですが・・・


ここで踏ん張って原因の詳細を理解すると、かなり実力つきますよ
ちゃーはん
会議室デビュー日: 2007/06/25
投稿数: 13
投稿日時: 2007-07-02 18:07
Atata!!さん、渋木さん、お返事＆あたたかいお言葉をありがとうございます。

引用:

ここで踏ん張って原因の詳細を理解すると、かなり実力つきますよ

たしかに、仰る通りですよね。
みなさんのような知識や技術を身に付けられたらと思ってはいるんですが
とことん突き詰めていく時間的余裕と自分自身の気力が無くて・・・
#これもいい訳ですね
ついつい、まずは「利子だけでも払って」っと、なってます。

ところで再入の問題についてなんですが
色々探ってみると「CoRegisterMessageFilter」の「HandleInComingCall」とかを使うとうまく調整ができるみたな資料がありました。
ただそれくらいで、具体的な内容が分かっていません。
#一応自分なりに調べたのですが・・・
自分の勘違いで全く関係が無いものかもしれませんが、
それも含めてお分かりでしたら教えていただけないでしょうか。

毎度、図々しいお願いで申し訳ないですが、宜しくお願いします。
Atata!!
常連さん
会議室デビュー日: 2007/05/22
投稿数: 20
投稿日時: 2007-07-02 20:10
引用:

ところで再入の問題についてなんですが
色々探ってみると「CoRegisterMessageFilter」の「HandleInComingCall」とかを使うとうまく調整ができるみたな資料がありました。

自分の勘違いで全く関係が無いものかもしれませんが、
それも含めてお分かりでしたら教えていただけないでしょうか。

これなら再入を遅延させることができるのではないかと期待しましたが、結果は惨敗でした。
MSDNによると今回のパターン(CALLTYPE_TOPLEVEL_CALLPENDING)では
許可か拒否のどちらかしか選択できないとのことらしいです。
# CALLTYPE_TOPLEVEL_CALLPENDING
# A new top-level call has arrived with a new logical thread identifier and
# the object is currently waiting for a reply from a previous outgoing call.
# Calls of this type may be handled or rejected.

まぁ、CoRegisterMessageFilterによって、この意図せぬ再入を防ぐことはできると分かっただけでも勉強になりました。

[ メッセージ編集済み 編集者: Atata!! 編集日時 2007-07-02 20:27 ]
れい
ぬし
会議室デビュー日: 2005/11/01
投稿数: 346
投稿日時: 2007-07-02 20:50

なんかAtataさんのソース、ダウンロードしてみました。

#AtataさんってCOM研究所の方だったんですね。
#お世話になってます。

うごかしてはみましたが、
地獄っぽいですね

過去の遺産を引きずるとどんどんややこしいことになるので
COMもATLも捨てて欲しいんですが、
かといって過去の遺産を「サポートしない」というと
誰も使ってくれないし。

WPFだとかWinFXだとか、新しい技術はどんどん出てくるのに、
VistaもLonghornも中身はCOMだらけでした。

マネージだけで何とかなる世界すら程遠いのに。
COM全廃はいつの日か。

#DOS時代は楽だったなぁ。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2007-07-02 20:56
引用:

過去の遺産を引きずるとどんどんややこしいことになるので
COMもATLも捨てて欲しいんですが、


うーん、今回の件の主たる原因は COM でも ATL でもなくて、サービスの基本設計がまずかった（＝呼び出し側で複数同時呼び出しをシリアライズしなければならない）だけだと思うんですが…

# ここを修正しても特に他に悪い影響は及ぼさないような気もします。


[ メッセージ編集済み 編集者: 渋木宏明(ひどり) 編集日時 2007-07-02 20:57 ]
ちゃーはん
会議室デビュー日: 2007/06/25
投稿数: 13
投稿日時: 2007-07-03 09:30
Atata!!さん、れいさん、渋木さん、ありがとうございます。
みなさん、お忙しいのに色々と教え頂き感謝してます。


引用:

Atata!!さんからの引用

これなら再入を遅延させることができるのではないかと期待しましたが、結果は惨敗でした。

そうですか～
あれから自分も引き続き調べていたんですが、何だかダメっぽいなっていう感じはしていたんですが・・・、残念です。
でも、こういったものもあるんだってことだけでも自分も勉強になりました。
何かと試して頂き、本当にありがとうございます。



引用:

れいさんからの引用

DOS時代は楽だったなぁ。

自分も大昔、少しだけRDB(dBaseⅡ。ふ、古い)絡みでDOSを使ったことがありますが、同感です。
そもそもFD１枚にOSが入って、起動できたんですもんね～
今考えるとある意味、すごいなって思います。
#けっして懐古主義者じゃないんですけど。(笑


引用:

渋木さんからの引用

今回の件の主たる原因は COM でも ATL でもなくて、サービスの基本設計がまずかった

自分の推測なんですが、問題の機能はもともとは無くて、途中で要望があって
無理矢理追加されたもののような感じなんですね。
他と比べても、なんか苦し紛れの、まさに「とりあえず利子だけでも払って」的に作りましたっていう雰囲気で・・・
本来ならばもっと根本の部分の見直しをって思うのですが、
実は複雑に絡んでいて、他の部分にも影響があって(このこと自体、あまり良くないですよね)、
そこまで手が出せない状況なんです。

時間的制約もあるので、今回はやっぱりAP側の運用で回避してもらう方向なるかなって考えいます。
#正直、ここまで皆さんに助け頂いたのに方策を見出せない自分が情けなく、且つ悔しいんですが


«前のページへ 1|2|3|4|5|6

スキルアップ／キャリアアップ（JOB@IT）