spec does not mentioned that setImmediate is implemented as a low-priority idle queue

[toddreifsteck]

No description provided.

[toddreifsteck]

Changing issue text to be more accurate

[igrigorik]

What happens in the case where my application is consistently taking ~16ms to process each frame and there is no idle time (e.g. my game loop is just barely keeping up), will the setImmediate queue be delayed indefinitely?

[tobint]

I think that's an implementation detail that can be left up to the UA. I think you'll find it rare to have a game loop that blocks exactly a full frame each time. Either the frame will blow the budget, and bleed into the next frame, creating idle space in that frame to process the queue, or you'll leave yourself some space in the current frame. Yes, it is possible to fill the frame largely leaving it so the callback doesn't get serviced, but it's unlikely to leave zero budget for an extended period of time. I don't think you'd have an issue if the callback in setImmediate was processed at low priority. The aim is reducing CPU utilization and power consumption and occasionally has the benefit of improving performance.

[igrigorik]

@tobint I don't disagree, but having previously spent many years in analytics world... I know that there is very low tolerance for "it'll execute sometime; there is a tiny chance it won't" type of semantics, and I envision analytics and related use cases being one of the key customers for an API like this, hence the question.