On Mon, 11 Aug 2008 23:37:01 -0700, Alhambra Eidos Kiquenet
<Al*******************@discussions.microsoft.comwr ote:
Hi misters,
Is it possible "kill" the thread of Backgroundworker ?
No, don't do that. The BackgroundWorker runs on a thread pool thread.
It's not nice to kill thread pool threads, even if you could while it's
waiting for a COM call to return (and you usually can't).
In my Dowork event, I have NOT While for do e.Cancel = true, only have a
call to external COM.
If I want cancel, calling CancelAsync, not cancels the call to COM.
It depends on the COM object. Ideally, a COM object would not have a
lengthy or potentially hanging operation that isn't cancellable through
COM itself. Killing threads is a bad idea whether from managed code or
not.
But if you really need to deal with this and can't abort the call to the
COM object directly, I think you're going to have to dedicate a thread you
create for the purpose that you can kill "safely" (not that there's any
truly safe way to kill a thread, but I just mean safer than killing off
thread pool threads).
Note that managed threads don't response to Thread.Abort() unless they are
executing managed code. Any thread stuck in a COM call and which you want
to kill, you're going to have to make sure you have an unmanaged thread
handle that you can kill. As far as I know, the only reliable way to do
this is to call the COM object's method from your own _unmanaged_ thread.
You can either do that via p/invoke or write your own C++/CLI wrapper to
do it.
Basically, if you _really_ need to use thread-killing as a way of aborting
an unmanaged COM object, you're in a pretty ugly situation. I don't think
there's really any _good_ way to solve it.
Pete
