Jane Style★144　

世界が認める天才プログラマー 山下遼太氏の
超高機能5ちゃんねるブラウザー　「Jane Style」　専用スレ （ソフトウェア板）

■ Jane Style公式HP （DL先）
http://janesoft.net/janestyle/　

Jane Style ヘルプ
http://janesoft.net/janestyle/help/index.html
　
（株）ジェーンHP＝http://janesoft.net/
Jane Style wiki＝http://ja.wikipedia.org/wiki/Jane

前スレ
Jane Style Part143
https://egg.5ch.net/test/read.cgi/software/1521284142/

例のデッドロックと例外0eedfadeの話

ttps://marc.durdin.net/2012/08/locating-delphi-exceptions-in-a-live-session-or-dump-using-windbg/
これを見つけたけど関係あるかよくわからず読まなかったが、隣の記事
https://marc.durdin.net/2012/08/waitforsingleobject-why-you-should-never-use-it/
WaitForSingleObject. Why you should never use it.
モロこの問題じゃない？
COMとかOLEみたいなのが隠れウインドウ(※2)を扱うとメッセージが発生して、
メインスレッドでWaitForSingleObject使ってるとメッセージが詰まっちゃうってことじゃないかな。

Except that WaitForSingleObject and its big brother WaitForMultipleObjects are dangerous.
The basic problem is that these calls can cause deadlocks, if you ever call them from a thread that has its own message loop and windows.
That’s okay, you say, I don’t have any UI except in my main thread.
But any thread that uses COM can have hidden COM helper windows when doing RPC (and see below for more on this).
And other libraries can create their own windows as well, such as the ADO libraries.

So what causes the deadlock? Well, I’ll illustrate with the scenario we ran into.
Some old code (that I wrote, okay, okay) created a thread (we’ll call it BackgroundThread).
BackgroundThread used TThread.Synchronize to periodically update the UI status about a background database process it was running.
It doesn’t really matter what it was doing, but the use of Microsoft’s ADO database library meant that this thread was creating a hidden window,
with the class ADODB.AsyncEventMessenger.
Behind the scenes, a second window was automatically created by Windows once we had the first window in the thread, and this one had the class name IME.

(※2)https://egg.5ch.net/test/read.cgi/software/1521284142/813

対処法らしきもの
In any case, to make your own code more robust:

1.Determine, when using synchronisation calls, if there is any chance that windows could be created by your thread,
and if so, use MsgWaitForMultipleObjects and a message loop instead of WaitForSingleObject or WaitForMultipleObjects.
Check the libraries you are using, and if you are using COM, it’s safest to assume that windows will be created.
2.Don’t use the TThread.Synchronize procedure. Recent versions of Delphi include TThread.Queue, which is asynchronous, and so avoids this deadlock.
3.Think carefully about whether a thread is the right solution to the problem.
4.Don’t use the KLF_SETFORPROCESS flag!


Delphiの不具合というより、
いろいろな人がコンポーネントを作るから、
Delphiに蔓延してる病気みたいなものだろう。
だからといって長年?放置していい理由にならないけど。

通信が滞った場合に、メッセージが詰まり、謎例外0eedfadeでソケットのスレッドが終わって、メインスレッドが無限に止まると。
65秒パッチはある意味正解だったようだな≒MsgWaitForMultipleObjects気持ち悪いAPIだけど、
特定WM_〜で動くみたい。
OpenJane〜JaneLovelyソース見る限り、単純にこれに変えても結果は同じかな。
GUIにメッセージ送るやりかた工夫しないとね。