On Tue, Feb 28, 2012 at 8:27 AM, René Ruppert <[email protected]>wrote:
> The problem I'm having with the solutions you and Rolf propose is that one > might end up with a couple of threads waiting to terminate. Imagin that > switching to a tab in a tab controller starts a thread that does some > hefty work. Then user switches tabs and the thread is signaled to abort > ASAP but the UI reacts instantly. A second later user switches again to the > second tab. Another thread is started where the first one might not have > reached the first point where it could exit (maybe it is still trying to > reach a server over the net). Now there Are two threads. This can go on and > on and while it is uncommon to cause problems I'm wondering if that is just > as it is and I should not worry? > I wouldn't worry. If it's trying to reach a server, the thread isn't actually doing anything at all, it just sits there, waiting (which can hardly be defined as "hefty work"). If you are really doing hefty work, it'll be in your code and you can quite easily cancel it within a few seconds yourself. It wouldn't be a problem unless you'd have several threads consuming all available cpu at the same time, and if each thread is cancelled within a reasonable amount of time (even 5-10 seconds would do), I can't see how the user would run into problems unless he is actually stress-testing the application. Rolf
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
