On 8/5/13 Aug 5, 1:40 PM, Scott Palmer wrote:
On 2013-08-05, at 12:49 PM, David Hill <david.h...@oracle.com> wrote:
On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote:
The idea of user event starvation has been mentioned before and has me a little
confused… Why aren't things handled as a simple queue, with no priorities or
anything, so starvation is impossible? Is this something the OS is doing?
There is a "simple" user input queue - the problem is that we dispatch those
arriving events on the user event *thread*, and that thread is used for a lot of thing
other than user input. It is not so much the cost of handling the input, but rather the
cost of handling the actions after input.
Right, I guess I don't have a complete picture of the threading model.
I think that there is a relatively small number of people that do - and I count
myself as someone that has a good, but partial, understanding of it.
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".
I suspect I am oversimplifying. If there is somewhere to go to get a idea of
the actual threading model please point me in the right direction.
As part of our "porting guide" which will just be part of the openjfx wiki -
this is something that I want to write up, at least in overview. Not there yet though.
I suspect that some of the details will be changing over the next while anyway.
The repo refactoring now allows us to clean up some of the rather convoluted
means of communicating from the API through quantum to Prism and Glass.
Dave
--
David Hill <david.h...@oracle.com>
Java Embedded Development
"The conventional view serves to protect us from the painful job of thinking."
-- John Kenneth Galbraith (1908 - 2006)
