A different way to handle pulse timing

[Scott Palmer]

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 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.

Regards,

Scott