If the event buffer fills up, can setTimeout()'s fail to fire?

[espruino-discuss3]

Posted at 2014-11-15 by DrAzzy

I've been having some problems with my RF communication system. ( http://forum.espruino.com/conversations/255528/ )

What I do when expecting a packet is...

setTimeout("startListen()",200);
setTimeout("stopListen()",1000);

During this time, the Espruino is drowning in events and totally floored, and if it gets a transmission, it'll snap out of it when it does, but otherwise, it's effectively hung. But that's okay, the timeout should stop it, and it should return to functionality within a second if it doesn't get a response (which is inevitable, since these rf transmitter/receivers suck). But... sometimes it seems to take many many seconds for the stopListen() to happen and unlock the Espruino, and a few times, it never happened, even minutes later, the Espruino was still totally floored.

Is there a bug in Espruino here? Any thoughts on how to get it to stop listening after a time, and have it reliably do so even though the Espruino is heavily loaded?

[espruino-discuss3]

Posted at 2014-11-17 by @gfwilliams

That's interesting - I guess it is possible that Espruino can get totally overwhelmed. The code looks a bit like this:

function onIdle() {
  while (hasEvent) handleEvent();
  while (hasTimer) handleTimer();
}

So if you get so many input events that the queue can never get emptied, it'll get stuck. I'll file a bug for this and will fix it for 1v72 - probably doing something like:

function onIdle() {
  var howMany = getHowManyEvents();
  while (howMany--) handleEvent();
  while (hasTimer) handleTimer();
}

---

Posted at 2014-11-17 by DrAzzy

Aaah, so it was filling up the queue so much that the events were coming in faster than the Espruino could clear the queue out to check for timers.

I'll try it out once a fix is in the github builds.