undefined | Better HN

0 pointsSomeone14y ago0 comments

If you move code that used to run (and was tested to) on the main thread to another thread, and run that thread in parallel with the main thread, you are creating a huge opportunity for race conditions.

Some applications may run fine, but I bet you will find a lot that do not, even ignoring timing differences that may cause problems with games.

0 comments

davesims14y ago

I guess I don't see how that's any different than performing any other blocking operation off the main/UI thread, either on a hand-rolled secondary thread or using a util class like AsyncTask which handles that for you.

It seems to me race conditions are no more or less of a concern for rendering animations than updating data -- and probably less, actually, since there's probably not much contention for animation resources, and if there is contention, synchronization of access to drawables should be straightforward.

SomeoneOP14y ago

The post I replied to speculated that it would be possible to change the system's behavior without recompiling apps.

That would change the rules from "model updates and screen redraws never run concurrently" to "...will typically run concurrently". I think you agree that is asking for problems.

Of course, it is possible to adjust the system to apply different rules to different apps, but then apps would have to be changed to advertise "I am fine with running updates on a different thread". I think newer versions of Android already have some of that.

j / k navigate · click thread line to collapse