1

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?

Steve Sheldon
  • 6,421
  • 3
  • 31
  • 35
  • So is your question how to prevent the Cross Thread exception but yet run on a different thread? – Brad Semrad Jan 25 '12 at 20:32
  • I'd love to know how you plan to collect managed thread stacks. The only solution I know of so far is to implement your own custom, small debugger that you fire up, attach to your app and have it dump stacks, then detach, report and die. – antiduh Jan 25 '12 at 21:07

4 Answers4

5

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.

Fredrik Mörk
  • 155,851
  • 29
  • 291
  • 343
  • Thanks for the advice, we do actually put a lot of work on other threads already, when working with resources like images though, you have to monitor them so no two threads try to use them at once. Then you have the risk of deadlocks so thats how I got here. – Steve Sheldon Jan 25 '12 at 20:35
  • I should also mention theres over a million lines of code here :-) – Steve Sheldon Jan 25 '12 at 20:40
  • 'when working with resources like images though, you have to monitor them so no two threads try to use them at once' is this particularly difficult? What's so special about images? An image is an object instance, like most other stuff? – Martin James Jan 25 '12 at 21:16
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 :)

Daniel Mošmondor
  • 19,718
  • 12
  • 58
  • 99
0

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

Community
  • 1
  • 1
Tamir
  • 2,503
  • 16
  • 23
0

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.

Mark Maslar
  • 1,121
  • 4
  • 16
  • 28
  • Thanks Mark, Asynchronous Programming is just fancy syntax for what I will do myself (since I have a .net 2.0 dependancy). What you are suggesting is what I am writing and the reason for the question. – Steve Sheldon Jan 25 '12 at 21:03
  • Thanks Steve; didn;t know that you were 2.0 dependent. Some of the nice things about Async though, are that it simplifies code development and makes the code's intent more readily apparent. – Mark Maslar Jan 26 '12 at 14:18