> Right, I guess I don't have a complete picture of the threading model. > > I assume that user events like mouse clicks and key presses are coming in > from some OS thread and queued on the "user event thread". Meanwhile things > like runLater() are also queued on the user event thread. If other user > events from the OS happened they would naturally be interleaved with runLater > type operations - everything eventually gets processed no matter how busy the > system is, no matter what you do on the user event thread so long as > eventually the operation completes. The cost of handling the input, would > either complete and then the next event is processed or they might trigger > additional work via runLater. The runLater stuff would be queued behind any > other OS events that have already been queued by the OS input thread, they > wouldn't "jump the queue".
That should basically be correct. The only wrinkle is that since we rely on the OS event queues (other than on embedded), if the OS does event prioritization it is possible that things won't get delivered to us in exactly the same order, but I believe in Glass we now make sure our events are not getting higher prioritization to avoid event starvation, so that the above thread model understanding should be correct. Richard
