Espruino interrupt handles or TestSet-TestReset-synchronized javascript equivalents for semaphore-thread handling

JavaScript in the browser is single threaded... and therefore, concurrency issues are rarely a problem.

It becomes a challenge when the native UI elements, for example, an input field is multi-threaded handled, and JavaScript can not made aware of that (The DOM and JavaScript events are not transaction like handled: While javascript does something on a key event, such as reading parameters from from the natively updated DOM, the values read are in flux because of the multi-threadedness of the operating system and native IO field updating on the next key stroke before JavaScript has completed is first event / service routine. The picture of the input field JavaScript gets can get inconsistent to - looking like - corrupted, and the JavaScript code is then flagged faulty...).

I wonder how Espruino handles the the update of interrupt handles that are held and controlled natively as well as in the JavaScript domain, such as the handles for setWatch(), setTimeout(), *setInterval(),... I use the following construct in the TOUCHR - module (for more details see http://forum.espruino.com/comments/11918647/):

tr.listen = function(b) {
    tr.l = b; if (b) { if (!tr.w) { 
    pinMode(xn,"input_pulldown");
    digitalRead(xp);
    digitalWrite([yn,yp],3);
    tr.w = setWatch(tr.track,xp,{edge:rising, repeat:false});
  } } else {
    if (tr.w) { clearWatch(tr.w); tr.w = null; }
  } return tr;
};

I wonder whether something relevant to my JavaScript application logic can happen in the time between the checking of the watch (handle tr.w) and the clearing of it, and if so, what would it be, and how would I be able to detect.

May be this question is trivial with (absolute) insight in the firmware, but I'm just not there yet and would like to know know for my design thoughts.