On Sat, Feb 25, 2012 at 9:50 PM, René Ruppert <[email protected]>wrote:
> Hi, > > > > one thing I have been wondering about is, how quickly apps written in ObjC > can cancel threads. > > Just one example: I have an app where I can check train schedules. I tell > it from where to where and it starts searching. Whenever I click some other > element in the tab bar, the search is interrupted immediately. > > Or App Store on the iPhone: you can switch between the different tabs and > each new one shows “Loading”. > > It is obvious that both examples above try to download something from the > web, but there are apps like iBook that only do local stuff, like rendering > page previews. Want to cancel? Just do it. It is reacting instantly. > How do you know the underlying worker thread has been stopped? It might be just the UI that reacts instantly. Rolf > > > Back in the good old days of .NET I was told: “Thread.Abort()” is evil! > Don’t use!”. So as a .NET developer I always have to abort in a clean way > but that makes apps less responsive. If you have to wait for the next web > call to return, for the next page to be rendered, etc it will be slow(er). > > > > > > If I check MSDN now, I see that Thread.Abort() will no longer abort > finally clauses. For me this means, Abort() no longer is that evil as it > was because you actually have a chance to clean up using a “finally” clause. > > > The questions: > > > > · What are the ObjC implementations doing to allow this quick > response? > > · As Thread.Abort() is safe in a Microsoft world these days, is > it also safe in Monotouch? > > > > René > > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch > >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
