On Tue, 4 Jul 2006 12:40:31 +0200, Torben Laursen wrote:
Yes changing the C++ code would be the best solution, but that is not
possible for a number of reasons.
The dll is loaded inside a class that I create when I run the thread.
Is there a way to simply dispose that class thereby stopping whatever is
running inside the dll?
No. Unfortunately, diposing an object does not automagically kill all the
threads that happen to be executing one of its methods or accessing one of
its member variables.
Or can I create a Thread inside a backgroundworking thread?
Sure you can but it wouldn't make much sense.
What you could do would be to manually create your own thread to execute
your C++ method instead of using the BackgroundWorker. Then you would have
your thread and be able to do whatever you want to do with it. Problem is,
you still won't be able to stop your long running C++ method. The Thread
class has an Abort() method that is supposed to stop the thread. Usage of
this method is strongly discouraged for many reasons (you'll find loads of
discussions about why Thread.Abort() is/is not evil on google). But in your
particular case, i think that even if you went to the dark side and used
Thread.Abort(), it still wouldn't work since i believe (not a specialist
though) that Thread.Abort() is not able to interupt unmanaged code and will
wait until your code comes back to the managed world before stopping the
thread.
Of course, the OTT method to do what you want to do would simply be to
launch a new process and execute your method in this new process
communicating back to the main process via .NET Remoting or some other
means. Then, should you need to stop the operation, you'd be able to kill
the worker process (potentially creating resources leaks).
