4 ms·

But the article is not about the precision of timers happening at exact moments. It's about the nature of their relative timings. I don't see why the OS would n

by _getify 11y ago

But the article is not about the precision of timers happening at exact moments. It's about the nature of their relative timings. I don't see why the OS would need to be involved in the latter.

deleted 11y ago
[deleted]
DougMerritt 11y ago
If the threads and their scheduling are implemented wholly by the language, not the OS, then perhaps the ordering of their wake-ups could be guaranteed -- although I'm not sure these languages do guarantee it. Maybe they had some reason for using a LIFO instead of a FIFO, who knows; one needs to check these things. However, the thing that triggered me to comment was this part: > If it runs significantly after 953ms, that’s OK, but there probably needed to be a good reason, like the entire thread being blocked unexpectedly. This is simply mistaken, in strongly implying that it takes unusual conditions for events to lag significantly; actually that is just normal functioning, and does not need "unexpected blocking" or anything else unusual or rare to occur. It is ameliorated a lot by avoiding heavy loading of systems (that doesn't fix it, but it can reduce strange behavior down to a statistically tolerable level).
- _getify 11y ago
  > If the threads and their scheduling are implemented wholly by the language There's just one thread, one event loop, for all of JavaScript... so we're not talking about true thread-level race conditions. > strongly implying that it takes unusual conditions for events to lag significantly As far as expectations of software running inside of web pages, it is in fact quite exceptional for there to be significant delays between when you expect for something to happen and when it actually happens. For example, if I set up a timer for 953ms from now, and it actually runs at 3953ms from now, that extra 3 seconds is extremely uncommon for the UX expected on the web. I think the disconnect here is that you're really asserting things about what happens at the OS level, where multiple threads and real I/O are happening, etc. I'm entirely talking about JavaScript, which is single-threaded, and where asynchrony is just simple event-loop concurrency (interleaving actions). It means that two timers should, in simplest terms, order themselves according to normal expectations. It'd be unusual for there to be significant deviations.
  - DougMerritt 11y ago
    Ok, so long as you know all these things to be true of JavaScript, and to be guaranteed in the future also, then well and good. I thought it was merely hope, which set off my internal alarm bells. Because of that yellow alert, I neglected to say before: I love projects like this, and I really like what you're aiming at. Also there's something about timers in particular that I think makes them cool. I should have said so at the start.

by _getify 11y ago

But the article is not about the precision of timers happening at exact moments. It's about the nature of their relative timings. I don't see why the OS would need to be involved in the latter.

deleted 11y ago

[deleted]

DougMerritt 11y ago

If the threads and their scheduling are implemented wholly by the language, not the OS, then perhaps the ordering of their wake-ups could be guaranteed -- although I'm not sure these languages do guarantee it. Maybe they had some reason for using a LIFO instead of a FIFO, who knows; one needs to check these things. However, the thing that triggered me to comment was this part: > If it runs significantly after 953ms, that’s OK, but there probably needed to be a good reason, like the entire thread being blocked unexpectedly. This is simply mistaken, in strongly implying that it takes unusual conditions for events to lag significantly; actually that is just normal functioning, and does not need "unexpected blocking" or anything else unusual or rare to occur. It is ameliorated a lot by avoiding heavy loading of systems (that doesn't fix it, but it can reduce strange behavior down to a statistically tolerable level).

_getify 11y ago
> If the threads and their scheduling are implemented wholly by the language There's just one thread, one event loop, for all of JavaScript... so we're not talking about true thread-level race conditions. > strongly implying that it takes unusual conditions for events to lag significantly As far as expectations of software running inside of web pages, it is in fact quite exceptional for there to be significant delays between when you expect for something to happen and when it actually happens. For example, if I set up a timer for 953ms from now, and it actually runs at 3953ms from now, that extra 3 seconds is extremely uncommon for the UX expected on the web. I think the disconnect here is that you're really asserting things about what happens at the OS level, where multiple threads and real I/O are happening, etc. I'm entirely talking about JavaScript, which is single-threaded, and where asynchrony is just simple event-loop concurrency (interleaving actions). It means that two timers should, in simplest terms, order themselves according to normal expectations. It'd be unusual for there to be significant deviations.
- DougMerritt 11y ago
  Ok, so long as you know all these things to be true of JavaScript, and to be guaranteed in the future also, then well and good. I thought it was merely hope, which set off my internal alarm bells. Because of that yellow alert, I neglected to say before: I love projects like this, and I really like what you're aiming at. Also there's something about timers in particular that I think makes them cool. I should have said so at the start.