The only way you can be absolutely, positively sure the operation runs to
completion is to write it using unmanaged code - the runtime will not
interrupt unmanaged code except when shutting down the entire runtime, and
even then only after a watchdog timeout. If you are accessing hardware you
may already be using unmanaged code - without more description of how you
manipulate the hardware it is impossible to tell. And even then if some
piece of code calls Process.Kill() you can be terminated. There are no
absolute guarantees.
The ThreadAbortException can be thrown manually, and it is also injected
into a thread when an appdomain gets unloaded. This exception will interrupt
threads executing managed code, even in a finally block. There are a few
things you can do to minimize your exposure in managed code. First, run this
code in a separate thread that you create yourself (or use a threadpool
thread) and do not expose the thread object you are using. This prevents
other code from manually calling Thread.Abort on that thread since it will
not have a reference to it. This will protect you against an arbitrary
client aborting the thread, but it still leaves you exposed to an appdomain
getting unloaded.
It may be that you don't really need to run to completion. Any hardware
access with tight timing requirements should be done in a device driver, not
in managed code. Perhaps if you describe what you want in more detail
someone here can be of more help.
"Jeff" <an*******@discussions.microsoft.com> wrote in message
news:5B**********************************@microsof t.com...
I am running a worker thread that manipulates some hardware setting every
so often. My problem is that the hardware manipulation cannot be
interrupted once it has started.
How can I ensure that the entire operation will run to completion even
when the ThreadAbortException is thrown?
Thanks,
Jeff
