Hi Daniel
A couple corrections to your points...
| 1. Your finalizer can be called by any thread at any time, or not at all.
Actually, finalizers are only called by the Finalizer thread. It's a
high-priority thread inside the CLR. You are correct that it runs
non-deterministically, and under certain circumstances, may not run a
particular finalizer. It is bad practice to rely on finalizers.
| 2. If you block this thread you delay garbage collection and you may even
| cause deadlocks. (Or even force CLR to skip GC prior to process exit if you
| block it during process termination)
You should not do anything that may block the finalizer thread. Although
this won't prevent GCs from occuring (this happens on a different thread
which can't be blocked by user code), it may prevent other finalizers from
being run.
| 3. You can't touch ANY other managed object. These may already be collected!
| Finalizers are for UNMANAGED resources only.
This is a common misconception. If you can touch another managed object,
then it has not been collected. The problem is, the object may have been
*finalized*, which means it may be in an invalid state. You should not
touch other managed objects in the same finalization graph (touching a
global or static object is ok).
Finalizers should definitely be used to free unmanaged resources, but you
should follow the Dispose Pattern to minimize the chances of finalizers
being run.
Hope that helps
-Chris
--------------------
| Hi,
|
[quoted text clipped - 123 lines]
| > private AutoResetEvent stopEvent = new AutoResetEvent( false );
| > }
Daniel Petersson, Cefalo - 31 Mar 2005 06:25 GMT
Hi, Chris
I stand corrected :)
// Daniel
ps I didn't realize that a GC was performed even if i block
the finalizer during process termination. I always assumed
that it was the same thread that ran the finalizers as was
responsible for the collection of memory.
> Hi Daniel
>
[quoted text clipped - 170 lines]
> | > private AutoResetEvent stopEvent = new AutoResetEvent( false );
> | > }
I think asynchronous delegates are what I need. As they use the ThreadPool,
which utilises background threads, is it possible for an executing thread in
the pool to be stopped between BeginInvoke and EndInvoke on the delegate?
Sorry if it is a dumb question, but I'm a complete beginner on managed
threads.
Thanks
> Hi,
>
[quoted text clipped - 123 lines]
> > private AutoResetEvent stopEvent = new AutoResetEvent( false );
> > }
Daniel Petersson, Cefalo - 31 Mar 2005 06:17 GMT
Hi,
It is not possible to stop any async call in any simple manner
due to the nature of the programming model. Sure you can
save a ref to the thread and then call Thread.Abort on that
reference, however I consider it rather bad programming to
abort threads like this, instead try to find a controlled execution
flow that solves the problem instead.
// Daniel
> I think asynchronous delegates are what I need. As they use the ThreadPool,
> which utilises background threads, is it possible for an executing thread in
[quoted text clipped - 131 lines]
> > > private AutoResetEvent stopEvent = new AutoResetEvent( false );
> > > }
Beth Phillips - 31 Mar 2005 10:21 GMT
Sorry, I didn't make myself clear. What I meant was when the app shuts down,
any background threads will automatically stop. Does this mean that any
methods that are queued for execution by the thread pool but haven't yet
executed will not be called? I don't want to stop an async call myself, but
want to know what happens if the app shuts down between BeginInvoke and
EndInvoke being called (assuming that scenario is possible).
Thanks for your help
Beth
> Hi,
>
[quoted text clipped - 142 lines]
> > > > private AutoResetEvent stopEvent = new AutoResetEvent( false );
> > > > }