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.

 

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

Reply via email to