-3

I'm trying to dispatch my thread as

private Thread thread;
. . .
if(thread != null && thread.IsAlive) thread.Abort();
. . .
thread = new Thread(myProcess);
thread.Start();

to start over myProcess from the very beginning, if it is already run. However, it never ever comes to thread.Abort(), and WPF UI responce time still quite bad.

How could I make it right way?

Pavel Khrapkin
  • 75
  • 1
  • 9
  • 4
    The methods do work. If the UI thread blocks, it's because something else is blocking it. Why use raw threads like this though? Why not use Task.Run and collaborative cancellation? Even with threads, `Abort` is considered a very bad idea. – Panagiotis Kanavos Oct 26 '17 at 13:25
  • 2
    *"How could I make it right way?"* - start [here](https://stackoverflow.com/q/1559255/1997232). – Sinatr Oct 26 '17 at 13:26
  • Check [Enabling Progress and Cancellation in Async APIs](https://blogs.msdn.microsoft.com/dotnet/2012/06/06/async-in-4-5-enabling-progress-and-cancellation-in-async-apis/). The classes aren't specific to asynchronous operations, they can be used just as easily with raw threads. It's "just" that using `Task.Run` instead of Thread is a *lot* easier. It also understands cancellation, so it the task won't even start if cancellation is signalled – Panagiotis Kanavos Oct 26 '17 at 13:28
  • It is not a sensible question. Beyond the rather bad practice, this code can't have anything to do with WPF perf. Use a profiler. – Hans Passant Oct 26 '17 at 13:33
  • Have you tried debugging? What happens when you pause execution? What is running in the UI thread? Check the `Parallel Stacks` window in the Debug menu. This will show you the running threads and their call stacks. Check the main thread's call stack to see where it's stuck – Panagiotis Kanavos Oct 26 '17 at 13:35
  • @HansPassant, answering your qtns: myProcess start over API an external application. I treat it as a blackbox, Parallel Stack couldn't help there. I try to abort it, if it is running. In this case - when WPF event happend (f.e. multiple button click), the thread should be already active, shouldn't it? – Pavel Khrapkin Oct 26 '17 at 14:02
  • 2
    Never ever call `Thread.Abort()` unless you are trying to crash out of your app. Aborting threads can leave the .NET run-time in an invalid state. In other words, if you call `Thread.Abort()` you must immediately then exit your app. – Enigmativity Oct 27 '17 at 03:38
  • Thanks for clarification, @Enigmatitity! It looks like thread.Abort(), and rthread.IsAlive check doen't works, becouse myProcess run over API an external sinchroneous process, and stay suspended till it completed. I still experiment with the technology Enabling Progress and Cancellation in Async APIs adviced by @PanagiotisKanavos to make the conclusion of my problem, hopely it comes soon – Pavel Khrapkin Oct 27 '17 at 05:00
  • Dear @PanagiotisKanavos, if i understand correctly the article you pointed, and my own experience with the progress bar, it required some "hooks" in the external app API, which i haven't. Task.Run, and cancellation should reffer to the API for cancelation token, not awailable for me. Example: I start long calculation in external Office app, f.e. Excel. How could I cancel this calculation, without aborting Excel? – Pavel Khrapkin Oct 27 '17 at 09:30
  • 2
    @PavelKhrapkin that's not a long calculation. There's no thread to abort, it's a different *process*. You are starting a different application using COM Automation. You don't need a separate thread to do that. Is that what you are trying to do? Stop *Excel* by aborting *its* thread? Then *that's* your external resource and cross-threading problem. COM object can only be used by the thread that created them. Aborting the thread doesn't mean the *process* dies either. You could end up with multiple Excel instances running in the background – Panagiotis Kanavos Oct 27 '17 at 09:48
  • @PavelKhrapkin post your Excel automation code and highlight what's blocking and what you want to cancel. You may not have to *block* waiting for the calculation (what calculation?) to complete. Excel doesn't freeze when loading data or calculating formulas. What kind of calculation do you perform? – Panagiotis Kanavos Oct 27 '17 at 09:51
  • I apologize for the long discussion; simple respond I haven't found in the Net expected.. Excel is an example. In fact, i start synchronous process of highlight some elements in Tekla CAD with quick fill of list Tekla object colorObject, then line: ModelObjectVisualization.SetTemporaryState(colorObjects, _color); ModelObjectVisualization.SetTransparencyForAll(TemporaryTransparency.SEMITRANSPARENT); ModelObjectVisualization.SetTemporaryState(colorObjects, _color); However, for the list with a lot of elements it takes long time, and keep user waiting. – Pavel Khrapkin Oct 27 '17 at 12:29
  • I found quite similar post: [link] (https://stackoverflow.com/questions/1559255/whats-wrong-with-using-thread-abort?noredirect=1&lq=1) with long conversation why thread.Abort is a bad stile, but without conclusion, how to do it right way? – Pavel Khrapkin Oct 27 '17 at 12:43

1 Answers1

1

So, with all conversations in my post, as well as discussions outside of StackOverflow, I found, that I ask about quite fundamental issue, which haven't any solution is the Microsoft Windows architecture:

When external task started in some thread with API, and it is running, there is no way to cancel this execution, and return it to the initial suspend status, but another API (as "Cancel" in ProgressBar) made specially to return it to the Idle Loop waiting.

In other time sharing OS such a special point exists, but not in Windows. As a result, when no Cancel API interface described, we should run another thread, possibly, from the tread pool to save CPU time in the system, and keep waiting, until unnecessary one would be completed.

Respond from Tekla developers confirm my conclusion: "Such methods do not exist. As I wrote before, implementing multi-threading in your app could not improve performance changing colors because TeklaStructures internal code does not use it."

Pavel Khrapkin
  • 75
  • 1
  • 9