Re: Relationship between Application.Exit() and AppDomain

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Jeff,

Thanks for replying. To answer your question whether I tried to find out why
Thread.Abort() didn’t terminate the foreground thread, - no, I didn’t even
try. First, I am lazy and I prefer to ask experts; this does save time in the
short run:) Second, the documentation on Thread.Abort says ‘The thread is not
guaranteed to abort immediately, or at all’ and that is enough for me (see
the first reason:))).

In my simplistic scenario the thread was doing something like this: while
(true) {}; so given the information I found at

http://www.ondotnet.com/pub/a/dotnet/2003/02/18/threadabort.html

I assumed there was no chance for that sort of thread to be aborted. Then I
asked myself a question why is it still aborted when it is created as a
background thread? I figured that trying to find an answer to this question
would take me an unjustified amount of time given the fact that stopping the
thread by Application.Exit() gives an immediate practical solution. I do need
to read the books you’ve recommended …

Regards,
SS


""Jeffrey Tan[MSFT]"" wrote:

Hi Sunny,

Thank you for explaining it in details.

Oh, I was not aware of that the foreground UI thread will block the
AppDomain.Unload() method with CannotUnloadAppDomainException. Have you
invested to find out why the Thread.Abort did not terminate the target
thread? I have had a hard time to understand why the thread did not
terminate.

Anyway, if Application.Exit() can terminate all the foreground GUI threads
in the target AppDomain, I think we can call Application.Exit() to
terminate all the UI threads in the target AppDomain and followed with an
AppDomain.Unload() method calling to clean up the target AppDomain.

<Shared Source CLI Essentials> explains the CLI(which is very similiar with
CLR) in source-code level, so it has a deeper insight than other CLR books.
<Customizing The Microsoft .Net Framework CLR> targets the CLR hosting
topics in depth.

Actually, I am the .Net CLR and VS.net debugging newsgroups MSDN
subscription support engineer, so it's my job and pleasure to help you
:-).(Also, I learned a lot in the newsgroup discussion)

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxxxxxxxxxx

This posting is provided "AS IS" with no warranties, and confers no rights.


.

Relevant Pages

  • Re: Relationship between Application.Exit() and AppDomain
    ... invested to find out why the Thread.Abort did not terminate the target ... if Application.Exitcan terminate all the foreground GUI threads ... in the target AppDomain, I think we can call Application.Exitto ... CLR) in source-code level, so it has a deeper insight than other CLR books. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Possible huge clue into unmanged/managed problem
    ... it's that service which is "dangerous by nature". ... > I'm wondering out loud if the CLR team cannot provide a cleaner way to ... > terminate a thread that would be internally implemented? ... > The Microsoft Office Web Components Black Book with .NET ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Possible huge clue into unmanged/managed problem
    ... it's that service which is "dangerous by nature". ... > I'm wondering out loud if the CLR team cannot provide a cleaner way to ... > terminate a thread that would be internally implemented? ... > The Microsoft Office Web Components Black Book with .NET ...
    (microsoft.public.dotnet.languages.csharp)