Re: Detach Application.ThreadException Event, really?
- From: "Buddhist.CHinA@xxxxxxxxx" <Buddhist.CHinA@xxxxxxxxx>
- Date: 15 May 2007 17:39:16 -0700
On May 15, 10:02 pm, Moty Michaely <Moty...@xxxxxxxxx> wrote:
On May 15, 1:35 pm, "Buddhist.CH...@xxxxxxxxx"
<Buddhist.CH...@xxxxxxxxx> wrote:
On May 15, 3:59 pm, Moty Michaely <Moty...@xxxxxxxxx> wrote:
On May 15, 3:48 am, "Buddhist.CH...@xxxxxxxxx"
<Buddhist.CH...@xxxxxxxxx> wrote:
On May 15, 2:04 am, Moty Michaely <Moty...@xxxxxxxxx> wrote:
On May 14, 7:45 pm, Andy <a...@xxxxxxxxxxxxxxxxxx> wrote:
On May 14, 8:32 am, Moty Michaely <Moty...@xxxxxxxxx> wrote:
Now that I think of it, it surely needs to be unsubscribed since
static events survive GC collections.
Think about it: Static events has a collection of references. There is
not way to the GC to know that instance has no references to it since
there is not destruction of finalization method for the static event
container to release these references for you.
It's a memory leak just like referencing a child object in a root
object...
Your logic is sound, but I don't think it answers the question. Think
about this; the AppDomain is being torn down, and the process itself
will terminate. After all that occurs, is there still really anything
left to garbage collect?
I don't know the answer myself, but it seems that in the managed world
these things will get cleaned up automatically, assuming no unmanaged
resources are held by a managed object.
Hi,
The memory leak is through the life cycle of your application.
After the application terminates, the memory space is reused by the OS
(It's the OS responsibility to manage the memory spaces).
But, there are services which in many ways will rarely terminate. In
these cases, static events GC is important especially if you use more
than one AppDomain.
Hope it answers the question :)
Moty- Hide quoted text -
- Show quoted text -
It makes much sense. That's why I couldn't find any evidence to check
out the detach of the static event. They were always single thread
apps enough for an example.
But you threw out another question, I didn't quite understand that "if
you use more than one AppDomain". Suppose that I got a single thread
app (non-server app) with multiple ADs, I had to subscribe
AppDomain.UnhandledException to handle unknown exceptions, and I also
subcribed Application.ThreadException. In the case, looks like it's
not necessary to detach it since the app temination does good, then
what should I consider with ADs? It there any concept about memory
leak occured in AD?
Thanks.
Hi,
Sorry but what I meant with more than one AppDomain is running more
that one application message queue.
Example:
// Thread 1
Application.ThreadException += ...
Application.Run();
Monitor.Wait(...);
// Thread 2
Application.Exit();
//Thread 3
Application.ThreadException += ...
Application.Run(new Form1());
This sample can lead memory leaks.
Moty- Hide quoted text -
- Show quoted text -
From your example, I don't think memory leak would happen.
Each process (main thread) has its own CLR runtime, so it could manage
its own static events. Then even there are several subscriptions, I
think they are independent, right?
HI,
It's right that each process has it's runtime, but still it is unable
to manage it's static events since GC is done only if there are no
more references pointing to a resource. Thus, static events survive
the GC since there will always be references pointing to them until
the events are unsubscribed.
Moty- Hide quoted text -
- Show quoted text -
I knew exactly what you meant. But could you please explain your
example a little bit more? I'm a little confused. How do the
references work in that case? I saw you launched 3 applications, but I
thought they were irrelative. Thanks.
.
- Follow-Ups:
- Re: Detach Application.ThreadException Event, really?
- From: Moty Michaely
- Re: Detach Application.ThreadException Event, really?
- References:
- Detach Application.ThreadException Event, really?
- From: Buddhist.CHinA@xxxxxxxxx
- Re: Detach Application.ThreadException Event, really?
- From: Moty Michaely
- Re: Detach Application.ThreadException Event, really?
- From: Buddhist.CHinA@xxxxxxxxx
- Re: Detach Application.ThreadException Event, really?
- From: Moty Michaely
- Re: Detach Application.ThreadException Event, really?
- From: Andy
- Re: Detach Application.ThreadException Event, really?
- From: Moty Michaely
- Re: Detach Application.ThreadException Event, really?
- From: Buddhist.CHinA@xxxxxxxxx
- Re: Detach Application.ThreadException Event, really?
- From: Moty Michaely
- Re: Detach Application.ThreadException Event, really?
- From: Buddhist.CHinA@xxxxxxxxx
- Re: Detach Application.ThreadException Event, really?
- From: Moty Michaely
- Detach Application.ThreadException Event, really?
- Prev by Date: Re: Finding Memory leaks
- Next by Date: RE: hide cursor for kiosk application (powerpoint)
- Previous by thread: Re: Detach Application.ThreadException Event, really?
- Next by thread: Re: Detach Application.ThreadException Event, really?
- Index(es):
Relevant Pages
|