Linked by David Adams on Mon 3rd Jan 2011 04:44 UTC
PDAs, Cellphones, Wireless "I'm a Mac and iOS developer and just spent the past week using a Windows Phone 7 powered Samsung Focus as my primary phone rather than an iPhone 4 as I have for the past three years [...] Anytime a new phone hits the market, I want to pick it up. I was also intrigued by the screenshots and previews I've been reading on Engadget for the past few months. Windows Phone 7 looked like nothing else I've seen on the market."
Thread beginning with comment 455976
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Let's see what happens..
by moondevil on Wed 5th Jan 2011 13:04 UTC in reply to "RE[5]: Let's see what happens.."
Member since:

It is a case of "Worse is Better".

The architecture requirements that you need to have to build a thread safe UI, provide minimal gains when compared to an UI which is single threaded and makes use of communication mechanisms between threads.

Having a multiple threaded UI, means you need to take care of:

- Who is holding which rendering context
- What threads are making use of which UI elements
- Which thread processes which UI event
- Race conditions to UI changes
- and so on

Having the UI event based and one thread responsible for drawing it, simplifies things a lot.

Reply Parent Score: 2

Neolander Member since:

Well, I was more thinking about event handling than drawing when talking about those asynchronous pop-up threads, but let's include drawing then.

When a button is clicked in an application, two totally separate processes occur :
-The button provides visual click feedback, through a "pressed" look.
-The application responds to the click by doing something insternally (click event handler).

So I can spawn two threads, one for the button-drawing job (which the application doesn't even control, it's all managed by the UI toolkit), and one for the event handling job (fully managed by the application).

The sole cases in which races and such may occur is when there's already one running thread doing the exact job we just asked for (drawing this precise button or executing this precise event handler, which cannot be run multiple times at once, a strange characteristic for an event handler).

In these case, which are very unlikely already, we have two options : putting the thread in a queue waiting for its previous incarnation to be done before running it, or just refusing to spawn another copy of it (which decision you take depends on which kind of application you're running).

Are async pop-up threads that much of a problem ?

Reply Parent Score: 1

_txf_ Member since:

not really, seeing as all (ui interacting) event handling must happen on the dispatch thread. thus events are managed sequentially. The rendering thread by it's very nature is 1 thread that handles all drawing.

The event handlers themselves can spawn other threads which might cause race conditions if the ui is dependent on the results of those threads. So:

"click go"-> event spawns work thread 1-> thread 1 doing a lot of work.

user clicks go again (as nothing is happening) -> event spawns work thread 2 -> thread 2 does very little work.

thread 2 then returns first and if data from thread 2 depends or is affected by data from thread 1 then you have a race.

This of course is *very* contrived. Anybody and their monkey would do some sort of safety checking if this situation is liable to occur.

So TL;DR. They are not a problem unless you're being a dumbass ;)

Reply Parent Score: 2