Thread.Abort（）之后的有趣延迟 [英] Interesting Delay After Thread.Abort()
本文介绍了Thread.Abort（）之后的有趣延迟的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
在一个线程上调用Abort（）方法后，我遇到了一个有趣的重新延迟延迟，但它只在我第一次调用它时发生。每次
之后，都没有延迟。
我在UI中有一个代表我打电话来更新进度表。 />
我使用基于按钮事件的Suspend（）和Abort（）方法。
当线程
正在运行。当我选择开始时，我启用取消&暂停按钮（
调用Abort（）或Suspend（））。问题发生在我第一次点击
取消（导致调用Abort（））。我将暂停&
取消按钮的状态更改回禁用状态并手动清除进度条。
我最终看到的是3按钮单击和
实际清除进度条和禁用按钮之间的-4秒延迟。我检查了
button_click事件处理程序，它运行良好，没有延迟。它看起来好像在事件和重新绘制之间存在某种延迟，
但这只是第一次发生。如果我再次开始和取消，
重绘立即发生（正如我所料）。
我没有任何计时器或任何其他运行这将导致
重新绘制被截获。有没有什么关于调用Abort（）
第一次会延迟重新绘制（可能是因为必须第一次为应用调用
GC或者什么）？
-
Doug Thews
客户解决方案总监
D& D咨询服务
----------------
访问我的技术博客：
http://www.ddconsult.com/blogs/illuminati/
I ran into an interesting re-pain delay after calling the Abort() method on
a thread, but it only happens the very first time I call it. Every time
afterward, there is no delay.
I''ve got a delegate inside the UI that I call to update the progress meter.
I use the Suspend() and Abort() methods based on button events.
I can watch the progress meter increase just fine when the thread is
running. When I select Start, I enable the Cancel & Pause buttons (which
call Abort() or Suspend()). The problem happens the very first time I click
Cancel (causing Abort() to be called). I change the status of the Pause &
Cancel buttons back to disabled and I manually clear the progress bar.
What I end up seeing is a 3-4 second delay between the button click and the
actual clearing of the progress bar and disabling of the buttons. I checked
the button_click event handler, and it runs through fine without delay. It
looks as if there''s some kind of delay between the event and the re-paint,
but it only happens the very first time. If I Start and Cancel again, the
repaint happens immediately (as I would expect).
I don''t have any timers or anything else running that would cause the
re-paint to be intercepted. Is there something about calling Abort() the
very first time that would delay a re-paint (maybe by having to invoke the
GC for the first time for the app or something)?
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
推荐答案
我不知道什么会导致延迟，但一般不应该调用线程。中止。它是.NET equivelent的TerminateThread并且有类似的问题，例如它可能过早地终止finally块。只有两种情况可以调用Thread.About
1）当你在当前线程上调用它时（所以你知道线程被破坏的情况）
2）当你拉下整个AppDomain时
首选带有标志的合作机制或调用Thread.Interrupt
问候
Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp：//news.microsoft.com/microsoft.public.dotnet.languages .csharp /< #u ************* @ TK2MSFTNGP10.phx.gbl>
我打电话后遇到了一个有趣的重新延迟
a线程上的Abort（）方法，但它只在我第一次调用它时发生。每次
之后，都没有延迟。
我在UI中有一个代表我打电话来更新进度表。 />
我使用基于按钮事件的Suspend（）和Abort（）方法。
当线程
正在运行。当我选择开始时，我启用取消&暂停按钮（
调用Abort（）或Suspend（））。问题发生在我第一次点击
取消（导致调用Abort（））。我将暂停&
取消按钮的状态更改回禁用状态并手动清除进度条。
我最终看到的是3按钮单击和
实际清除进度条和禁用按钮之间的-4秒延迟。我检查了
button_click事件处理程序，它运行良好，没有延迟。它看起来好像在事件和重新绘制之间存在某种延迟，
但这只是第一次发生。如果我再次开始和取消，
重绘立即发生（正如我所料）。
我没有任何计时器或任何其他运行这将导致
重新绘制被截获。有没有什么关于调用Abort（）
第一次会延迟重新绘制（可能是因为必须第一次为应用调用
GC或者什么）？
-
Doug Thews
客户解决方案总监
D& D咨询服务
----------------
访问我的技术博客：
http://www.ddconsult.com/blogs/illuminati/
---
收到的邮件经过无病毒认证。
由AVG反病毒系统检查（ http://www.grisoft.com）。
版本：6.0.771 /病毒库：518 - 发布日期：28/09/2004
[microsoft.public.dotnet.languages.csharp]
Off the top of my head I''m not sure what would cause the delay, but in general should should not call thread.Abort. It is the .NET equivelent of TerminateThread and has similar issues, for example it may terminate a finally block prematurely. There are only two situations where is is OK to call Thread.About
1) when you call it on the current thread (so you know what situation the thread is being ripped down in)
2) when you are pulling down the whole AppDomain
Prefer a cooperative mechanism with flags or calling Thread.Interrupt
Regards
Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<#u*************@TK2MSFTNGP10.phx.gbl>
I ran into an interesting re-pain delay after calling the Abort() method on
a thread, but it only happens the very first time I call it. Every time
afterward, there is no delay.
I''ve got a delegate inside the UI that I call to update the progress meter.
I use the Suspend() and Abort() methods based on button events.
I can watch the progress meter increase just fine when the thread is
running. When I select Start, I enable the Cancel & Pause buttons (which
call Abort() or Suspend()). The problem happens the very first time I click
Cancel (causing Abort() to be called). I change the status of the Pause &
Cancel buttons back to disabled and I manually clear the progress bar.
What I end up seeing is a 3-4 second delay between the button click and the
actual clearing of the progress bar and disabling of the buttons. I checked
the button_click event handler, and it runs through fine without delay. It
looks as if there''s some kind of delay between the event and the re-paint,
but it only happens the very first time. If I Start and Cancel again, the
repaint happens immediately (as I would expect).
I don''t have any timers or anything else running that would cause the
re-paint to be intercepted. Is there something about calling Abort() the
very first time that would delay a re-paint (maybe by having to invoke the
GC for the first time for the app or something)?
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
[microsoft.public.dotnet.languages.csharp]
但如果你知道你要永久摆脱线程，为什么不
调用Thread.A BORT（）？ Thread.Interrupt（）保留所有资源，
我想强制GC收集这些资源。
-
Doug Thews
客户解决方案总监
D& D咨询服务
----------- -----
访问我的技术博客：
http://www.ddconsult.com/blogs/illuminati/
" Richard Blewett [DevelopMentor]" < RI ****** @ develop.com>在消息中写道
新闻：Oc ************* @ tk2msftngp13.phx.gbl ...
But if you know you''re going to get rid of the thread permanently, why not
call Thread.Abort()? Thread.Interrupt() leaves all the resources in tact,
and I want to force the GC to collect those resources.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:Oc*************@tk2msftngp13.phx.gbl...
脱离我的脑海我不确定会导致延迟的原因，但是在一般情况下应该不应该调用thread.Abort。它是.NET等同于TerminateThread并具有类似的问题，例如它可能会终止一个
最终阻塞过早。只有两种情况可以调用Thread.About
1）当你在当前线程上调用它时（所以你知道
线程是什么情况）扯下来）
2）当你拉下整个AppDomain时
首选带有标志的合作机制或调用Thread.Interrupt
问候
Richard Blewett - DevelopMentor
http：//staff.develop。 com / richardb / weblog
nntp：//news.microsoft.com/microsoft.public.dotnet.languages.csharp/< #u ********* ****@TK2MSFTNGP10.phx.gbl>
在线程上调用Abort（）方法
之后我遇到了一个有趣的重新延迟，但它只是我第一次打电话就发生了。每次
之后，都没有延迟。
我在UI中有一个代表我打电话来更新进度
米。
我用基于按钮事件的Suspend（）和Abort（）方法。
当线程运行时，我可以看到进度表增加得很好。当我选择开始时，我启用取消&暂停按钮（
调用Abort（）或Suspend（））。问题发生在我第一次点击
取消（导致Abort（）被调用）。我将暂停&
取消按钮的状态更改回禁用状态，并手动清除进度条。
我最终看到的是按钮点击之间的3-4秒延迟
实际清除进度条和禁用按钮。我
检查了button_click事件处理程序，它运行良好，没有延迟。它看起来好像在事件和重新涂漆之间存在某种延迟，但它只是第一次发生。如果我再次开始和取消，
重绘立即发生（正如我所料）。
我没有任何计时器或任何其他运行会导致
重新绘画被截获。有没有什么关于调用Abort（）的第一次会延迟重新绘制（可能是第一次为应用程序或其他东西调用了
GC）？
-
Doug Thews
客户解决方案总监
D& D咨询服务
---------------- <访问我的技术博客：
http：// www。 ddconsult.com/blogs/illuminati/
---
收到的邮件经过无病毒认证。
由AVG反病毒系统检查（ http://www.grisoft.com）。
版本：6.0。 771 /病毒库：518 - 发布日期：28/09/2004
[microsoft.public.dotnet.languages.csharp]
Off the top of my head I''m not sure what would cause the delay, but in
general should should not call thread.Abort. It is the .NET equivelent of
TerminateThread and has similar issues, for example it may terminate a
finally block prematurely. There are only two situations where is is OK to
call Thread.About
1) when you call it on the current thread (so you know what situation the
thread is being ripped down in)
2) when you are pulling down the whole AppDomain
Prefer a cooperative mechanism with flags or calling Thread.Interrupt
Regards
Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<#u*************@TK2MSFTNGP10.phx.gbl>
I ran into an interesting re-pain delay after calling the Abort() method
on
a thread, but it only happens the very first time I call it. Every time
afterward, there is no delay.
I''ve got a delegate inside the UI that I call to update the progress
meter.
I use the Suspend() and Abort() methods based on button events.
I can watch the progress meter increase just fine when the thread is
running. When I select Start, I enable the Cancel & Pause buttons (which
call Abort() or Suspend()). The problem happens the very first time I
click
Cancel (causing Abort() to be called). I change the status of the Pause &
Cancel buttons back to disabled and I manually clear the progress bar.
What I end up seeing is a 3-4 second delay between the button click and
the
actual clearing of the progress bar and disabling of the buttons. I
checked
the button_click event handler, and it runs through fine without delay. It
looks as if there''s some kind of delay between the event and the re-paint,
but it only happens the very first time. If I Start and Cancel again, the
repaint happens immediately (as I would expect).
I don''t have any timers or anything else running that would cause the
re-paint to be intercepted. Is there something about calling Abort() the
very first time that would delay a re-paint (maybe by having to invoke the
GC for the first time for the app or something)?
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
[microsoft.public.dotnet.languages.csharp]
嗯，是什么让你相信？
Thread.Interrupt在线程上抛出一个ThreadInterruptedException，可以捕获，处理和如果线程真的想吞下去。
Thread.Abort在线程上抛出一个ThreadAbortException，可以捕获，处理但不能吞下，因为运行时会重新抛出异常。 br />
Thread.Abort的问题不是它可能会破坏正在执行的线程，问题是它可能会丢弃你的整个AppDomain，因为它从执行线程下面撕裂了地面 - 如我说可能扔在最后一块的中间。这不是一个稳定的方法。
释放线程资源的东西是线程的终止以及缺少对该线程对象的任何实时引用。只要有人没有故意阻止它，Thread.Interrupt应该能够将线程关闭。问题是操作系统没有一个API来强制线程终止而不破坏进程的稳定性，那么.NET将如何实现呢？至少将线程作为托管资源，损坏可以限制在AppDomain。
问候
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp：//news.microsoft.com/microsoft.public.dotnet.languages.csharp/< eu ************** @ TK2MSFTNGP11。 phx.gbl>
但是如果你知道你要永久摆脱这个主题，为什么不用
调用Thread.Abort（）？ Thread.Interrupt（）保留所有资源，
我想强制GC收集这些资源。
-
Doug Thews
客户解决方案总监
D& D咨询服务
----------- -----
访问我的技术博客：
http://www.ddconsult.com/blogs/illuminati/
" Richard Blewett [DevelopMentor]" < RI ****** @ develop.com>在消息中写道
新闻：Oc ************* @ tk2msftngp13.phx.gbl ...
Hmmm, what makes you believe that?
Thread.Interrupt throws a ThreadInterruptedException on the thread that can be caught, handled and if the thread really wanted to swallowed.
Thread.Abort throws a ThreadAbortException on the thread that can be caught, handled but cannot be swallowed as the runtime will re-throw the exception.
The problem with Thread.Abort isn''t that it may trash the executing thread, the problem is it may trash your entire AppDomain as it rips the ground from underneath the executing thread - as I said possibly throwing in the middle of a finally block. This is not a recipe for stability.
The thing that will free up the thread''s resources is the termination of the thread and the lack of any live references to that thread object. Thread.Interrupt should be able to bring the thread down as long as someone hasn''t purposefully tried to stop it. The problem is that that the operating system doesn''t have an API to force a thread to terminate without destabilizing the process so how would .NET achieve this? At least having the thread as a managed resource the damage can be limited to the AppDomain.
Regards
Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<eu**************@TK2MSFTNGP11.phx.gbl>
But if you know you''re going to get rid of the thread permanently, why not
call Thread.Abort()? Thread.Interrupt() leaves all the resources in tact,
and I want to force the GC to collect those resources.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:Oc*************@tk2msftngp13.phx.gbl...
脱离我的脑海我不确定会导致延迟的原因，但是在一般情况下应该不应该调用thread.Abort。它是.NET等同于TerminateThread并具有类似的问题，例如它可能会终止一个
最终阻塞过早。只有两种情况可以调用Thread.About
1）当你在当前线程上调用它时（所以你知道
线程是什么情况）扯下来）
2）当你拉下整个AppDomain时
首选带有标志的合作机制或调用Thread.Interrupt
问候
Richard Blewett - DevelopMentor
http：//staff.develop。 com / richardb / weblog
nntp：//news.microsoft.com/microsoft.public.dotnet.languages.csharp/< #u ********* ****@TK2MSFTNGP10.phx.gbl>
在线程上调用Abort（）方法
之后我遇到了一个有趣的重新延迟，但它只是我第一次打电话就发生了。每次
之后，都没有延迟。
我在UI中有一个代表我打电话来更新进度
米。
我用基于按钮事件的Suspend（）和Abort（）方法。
当线程运行时，我可以看到进度表增加得很好。当我选择开始时，我启用取消&暂停按钮（
调用Abort（）或Suspend（））。问题发生在我第一次点击
取消（导致Abort（）被调用）。我将暂停&
取消按钮的状态更改回禁用状态，并手动清除进度条。
我最终看到的是按钮点击之间的3-4秒延迟
实际清除进度条和禁用按钮。我
检查了button_click事件处理程序，它运行良好，没有延迟。它看起来好像在事件和重新涂漆之间存在某种延迟，但它只是第一次发生。如果我再次开始和取消，
重绘立即发生（正如我所料）。
我没有任何计时器或任何其他运行会导致
重新绘画被截获。有没有什么关于调用Abort（）的第一次会延迟重新绘制（可能是第一次为应用程序或其他东西调用了
GC）？
-
Doug Thews
客户解决方案总监
D& D咨询服务
---------------- <访问我的技术博客：
http：// www。 ddconsult.com/blogs/illuminati/
---
收到的邮件经过无病毒认证。
由AVG反病毒系统检查（ http://www.grisoft.com）。
版本：6.0。 771 /病毒库：518 - 发布日期：28/09/2004
[microsoft.public.dotnet.languages.csharp]
Off the top of my head I''m not sure what would cause the delay, but in
general should should not call thread.Abort. It is the .NET equivelent of
TerminateThread and has similar issues, for example it may terminate a
finally block prematurely. There are only two situations where is is OK to
call Thread.About
1) when you call it on the current thread (so you know what situation the
thread is being ripped down in)
2) when you are pulling down the whole AppDomain
Prefer a cooperative mechanism with flags or calling Thread.Interrupt
Regards
Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<#u*************@TK2MSFTNGP10.phx.gbl>
I ran into an interesting re-pain delay after calling the Abort() method
on
a thread, but it only happens the very first time I call it. Every time
afterward, there is no delay.
I''ve got a delegate inside the UI that I call to update the progress
meter.
I use the Suspend() and Abort() methods based on button events.
I can watch the progress meter increase just fine when the thread is
running. When I select Start, I enable the Cancel & Pause buttons (which
call Abort() or Suspend()). The problem happens the very first time I
click
Cancel (causing Abort() to be called). I change the status of the Pause &
Cancel buttons back to disabled and I manually clear the progress bar.
What I end up seeing is a 3-4 second delay between the button click and
the
actual clearing of the progress bar and disabling of the buttons. I
checked
the button_click event handler, and it runs through fine without delay. It
looks as if there''s some kind of delay between the event and the re-paint,
but it only happens the very first time. If I Start and Cancel again, the
repaint happens immediately (as I would expect).
I don''t have any timers or anything else running that would cause the
re-paint to be intercepted. Is there something about calling Abort() the
very first time that would delay a re-paint (maybe by having to invoke the
GC for the first time for the app or something)?
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
[microsoft.public.dotnet.languages.csharp]
---
收到的邮件被认证为无病毒。
由AVG反病毒系统检查（ http ：//www.grisoft.com) 。
版本：6.0.771 /病毒库：518 - 发布日期：28/09/2004
[microsoft.public.dotnet.languages.csharp]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
[microsoft.public.dotnet.languages.csharp]
这篇关于Thread.Abort（）之后的有趣延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
查看全文
