[過去ﾛｸﾞ] Jane Style★144　 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

279: 2018/05/10(木)19:16 ID:u731Wp890(1/4) AAS
>>22
実際には65秒では復帰せず、もっと多くの時間が掛かる模様。
なぜなら処理が詰まっているから。

2chｽﾚ:software
304
4.00正式版
固まっても65秒待てば復帰します
00278061:83CAFF→B6FF90

---

285(1): 2018/05/10(木)22:15 ID:u731Wp890(2/4) AAS
例のデッドロックと例外0eedfadeの話

外部ﾘﾝｸ:marc.durdin.net
これを見つけたけど関係あるかよくわからず読まなかったが、隣の記事
外部ﾘﾝｸ:marc.durdin.net
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.
省10

---

286(1): 2018/05/10(木)22:18 ID:u731Wp890(3/4) AAS
対処法らしきもの
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の不具合というより、
いろいろな人がコンポーネントを作るから、
省7

---

287: 2018/05/10(木)22:42 ID:u731Wp890(4/4) AAS
>>285-286
広告とか2chAPI-sidの取得って
WM_TIMERとか使ってるのかな？よくわかんない。
2chｽﾚ:software
2chｽﾚ:software
メッセージループ周りもなんかあるのはお察しだった。

2chｽﾚ:software
あとこれももしかしたらね。

2chｽﾚ:software
602に気づいていなかったが、
省8

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

ぬこの手 ぬこTOP 0.157s*