A different way to handle pulse timing

[David Hill]

On 8/5/13 Aug 5, 1:40 PM, Scott Palmer wrote:
> On 2013-08-05, at 12:49 PM, David Hill <David.Hill at 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.Hill at Oracle.com>
Java Embedded Development

"The conventional view serves to protect us from the painful job of thinking."
-- John Kenneth Galbraith (1908 - 2006)