COM interop threading problem

[Emad Attia]

We are using a COM library through interop (ESRI's lib). Since the library is sometimes slow we decided to create a dialog to allow the user to cancel a long running request. The request is running on a thread. Pressing the cancel button on that dialog will Thread.Abort() the request. The problem we are facing is that the application's behavior is unpredictable after the user performs several cancellations. Sometimes, the application waits forever (hangs) and sometimes it just takes all of the processor's time. As you can see there is little info here. The only thing that we know about the COM library is that it is running in a single threaded apartment - STA. Questions: 1. Is it possible to do this kind of threading work with an STA COM library through interop? 2. Is there any other way to do the same thing (other than aborting the thread)? 3. Do you have any experience with multi-threading ESRI tasks in .NET (not C++)? If yes, can you please provide any advice on how to tackle this problem. We posted this problem on ESRI's forums to no avail :confused: Any help is greatly appreciated. Thanks

[Judah Gabriel Himango]

This really sounds like a problem with the vendor's dll. Now, aborting threads is generally a bad idea; it's better to manually cancel by building the work to watch for a cancellation flag so that it can do the necessary cleanup. Without cleanup, as you've discovered, code is left in an unpredictable, volatile state. Emad, what happens if you run the work on a background thread? Then if the user cancels, would it be safe to leave the work running, but the user doesn't see the work running? If that's feasible, that may be your only option outside of having ESRI provide some cancellable work method.

Tech, life, family, faith: Give me a visit. I'm currently blogging about: God-as-Judge, God-as-Forgiver The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

[Emad Attia]

hi Judah, yes it seems like it is a problem with the vendor's library. I am not sure about the cancel flag. We are working with Legacy code that we need to wrap the cancellation code around (not new design). Also, having code littered with checks like (if cancelled) doesn't seem to be the best solution for us. We are running the work on a background thread as you suggested. Leaving the work to run sounds like a good idea. It is worth a try if all fails. Thanks for your help.