UI 线程在等待线程池完成销毁， 但是线程池里的线程又给 UI 线程 POST 了消息(不是 APC)，于是挂了，总结来讲，尽量不要让 UI 线程去做任何可能的等待
请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 3229 days ago, the information mentioned may be changed or developed.
 | 1 RLib OP 这里的 POST 表述不准确，应该是 SEND |
 | 2 yangff Jul 30, 2017 嗯…… 一个稍微比较坑一点的情节是这样的（ 比如 UI 线程接到某个 event，去尝试销毁另一个线程持有的对象（通过线程间通讯去要求对方销毁），而那个线程是这个 event 实际上的发起者…… 于是他在等待 eventhandler 结束…… 最关键的是，你在用 await + async 写这些代码的时候无比畅快…… 比如 label1.Text = await DoCompution()之类的…… 实际上都多多少少有些问题（ |
 | 3 limhiaoing Jul 30, 2017 |
| 4 yangff Jul 30, 2017 @limhiaoing 正确情况下是不会有问题的…… 然而你可能会再在里面写上一些看起来没问题的代码（或者你调用了一些库的实现有一些问题），导致整个东西 boom 掉…… 而且这些东西可能不是很可以预计…… 毕竟有可能有的库就是二进制分发的…… 连源代码都没有 |
| 5 limhiaoing Jul 30, 2017 @yangff 举个具体的例子看下呢？ |
| 6 limhiaoing Jul 30, 2017 @yangff 指的是看起来没问题的代码。 |
| 7 yangff Jul 30, 2017 @limhiaoing 不是很好举例子…… 一下想不起来之前出的问题了…… 大概的问题是出在 DoCompution 这里面调用了 DLL，这个 DLL 本身有一些问题会导致计算的这个线程等待一个 UI 线程那边的锁…… 反正只用 await/async 应该是安全的 |
| 8 yangff Jul 30, 2017 抽象一点说的话就是这样的，不过直接这样看其实感觉问题是很明显啦…… UIThread： 1. Lock 2. await (hold lock) Computation Thread: 1. Lock 2. deadlock.. |
| 9 RLib OP @limhiaoing 旁观者清当局者迷，大概说的就是这个，这你让别人怎么给你举例呢... 在解决完一个 bug 我们基本都会有个小结，但其实回顾来看，很少 bug 是超出认知范围的... |
 | 10 geelaw Aug 3, 2017 一个很矛盾的事情：如果你的 UI 线程等待一个线程池，那么你的 UI 已经卡了，这已经很糟糕了。 正确的异步是让线程池完成销毁的最后步骤为通知 UI 线程自己搞定了。 |
Select Language