如何在.net中除Main UI线程之外的其他线程上运行UI？

Question

I know there are other questions around this but most end up with the answer don't do what I am about to suggest. So I know you aren't supposed to. The reason for this question is I want to do it anyway, how can I do it...

Here is why I want to break the rules...

Let's say I have a complicated application, it's version 1 and we want our customers to submit errors to us in the event of crashes or hangs. Let's now say I have a button on the top of the main form they click to submit reports.

Let's now imagine that the application hung because of a deadlock...

It would be nice if that small piece of UI and a handler for that button could live on a thread other than the main ui thread so that it isn't caught up in the deadlock. When clicked it would gather all the call stacks for the other threads and submit them to our error reporting service.

Now, knowing the scenario, can this be done in .net?

Answer 1

Yes, there is no magic in creating UI on another thread than the "main thread". The important rule to always keep in mind is to interact with that UI on the thread that created it.

Still, I feel that you are attacking this from the wrong angle. You should probably instead make an effort to push all work off the main thread. That way you minimize the risk for that thread to freeze, and then you don't need to resort to unorthodox solutions for the error reporting.

Answer 2

I have various cases of creating forms on non-main thread, and it works fine every time.

Create a new Thread , and show a Form from it. New message loop will be created for that thread and everything will run fine.

What magic will you use to gather data from the crashed app and locked main thread, that's up to you :)

Answer 3

if application hung, your main message loop is dead, thus ui will not work. As workaround for your problem i'd consider usage of external application (another exe) which will be invoked in case of report

in any case, if you want to invoke UI from other thread you should perform context switch In case of winforms, follow this answer

Answer 4

It sounds like you'd like to keep the UI alive, even when some other operation is mired in a deadlock. If so, perhaps Asynchronous Programming would be of use. Using Async to manage a potentially hung up task would allow the remainder of the application to remain responsive.

we want our customers to submit errors to us in the event of crashes or hangs

You might also consider adding some degree if instrumentation/reporting, so that you'll have this data without requiring user input.