while loop reboots

@DanB, that's correct... all pulses go to the 8266 into the hardware interrupt that Espruino maintains on said pin. Espruino then looks at the watch debounce options and say: 'hold your horses', until I do not see the logic level 'holding' for the debounce time, I do not consider this a signal and interrupt that is worthy to put into the queue for the JavaScript execution - the invocation of the callback function set with the watch. That's by the way all happen in C... ;-) --- so when then either the internal 8266 communication is done or the current JavaScript section triggered from the last interrupt is completed, Espruiono then checks if there is an entry in the JavaScript event queue and directs its cycles to process the callback. There are basically / logically 3 'queues' or 'logical' cooperating threads - kind of - going on:

1. the ESP8266 firmware/wifi-ware thread with the highest priority, feeding from Espruino / JavaScript issued requests and feeds the Espruino JavaScript queue (for all the on(eventName...
   
2. the Espruino control thread that bridges the non-JavaScript world (hardware/device firmware) and the JavaScript execution (dealing with capturing interrupts and put them into the queue for the JavaScript side)
   
3. the JavaScript execution thread that should be done as quickly as possible in order to not choke off / starve the other ongoing things...
   
   

It's quite an elaborate coop between the layers / areas of concerns...

Espruino is a highly optimized, thoroughly event driven platform. I like it very much... Thinking is not linear, but that makes it fun.