This is a really simple ask..
const Sleep = msecs => new Promise( resolve => setTimeout(async ()=> await resolve(), msecs))
called by
await Sleep(5000)
Similar to the same in other c-based languages
That doesn't actually sleep; setTimeout is nonblocking - and setTimeout is also not in the language, it's only in the web, and in node.
My bad... I was doing it from memory instead of confirming it in code.
Shame that you did not know how to fix it but also impressed that you knew it did not work :)
I have updated it to work properly plus the call to make it work.
Also did not realize that setTimout was not a native javascript call.
setTimout has been working as long as i can remember (even before ecma i believe)
Fairly mystified how a language could function without some sort of capability to release control back to the OS.
My point being about setTimeout is not whether it is in the language spec... but instead that the language itself must contemplate a way to interact with the os to provide timer and thread management.
Given that Set can be polyfilled and Sleep can be polyfilled (as i have shown above) i would think that there is some way to include it as a new feature (supported by a polyfill that works everywhere that setTimout works)
Out of curiosity is there a version of javascript available somewhere that does not have a function similar to setTimout? (as opposed to just a theoretical and therefore pedantic limitation)
What you've shown above is not sleep - it's "delay". "Sleep" would block the thread and prevent JS from running until it woke up; setTimeout can't offer that semantic.
I'm sure there are a few that don't; certainly the common ones have setTimeout/setInterval - but there's no i/o in JS, and that seems unlikely to change.
Given that javascript is single threaded I am not sure that your distinction illuminates a functional difference. When you sleep in a multithreaded environment the other threads continue to run.
The definition of Sleep that i defined behaves as closely to what would happen in a multi-threaded c ish call. Are you now telling me that javascript is only single threaded in some other definition of the language not the one here? If so then what is the purpose of this forum ?
And if you are not aware of any functional javascript implementations that have no setTimeout and i am not aware of them then this is a non issue. I have 20+ years of working with javascript and have never heard of a useful version that does not have setTimeout. I would bet a penny that they just don't exist and therefore it is an irrelevant consideration.
Are you saying that the language is specified without this function? It has been in it since the mozilla only days. It is in every javascript book, on every javascript website.
If it is not part of the language specification why is it listed everywhere as part of the language?
If this is not the correct forum to suggest this as an enhancement then where should it be suggested?
More importantly what is the forum if not for such natural extensions to be discussed?
setTimeout queues up a function to run on the event loop. Other things on the event loop will continue to run.
JS is single threaded but that doesn’t mean setTimeout can block.
Yes, the language is specified without this function. There is no i/o in the language.
2 Likes
setTimeout queues up a function to run on the event loop. Other things on the event loop will continue to run // similar to other threads in a multi threaded environment... what is your point ?
JS is single threaded but that doesn’t mean setTimeout can block. /// once again multithreaded wait does not block the other threads... so what is your point?
Yes, the language is specified without this function. There is no i/o in the language // saying the same thing twice is not the same as responding to the substance of my issue... if this is not the place for this then where can it be added? if you do not know then where can i find someone who does?
The difference is that "sleep" blocks the current thread, and no other code runs on it. What happens on other threads is irrelevant. In JavaScript, there are no other threads, so something would only be "sleep" if it blocks all other javascript code from running, which setTimeout does not.
What that means is that you'd have to specify it separately in HTML (for browsers), and in node, and in any other engine in which you wanted it available - there's no universal location for it.
What happens on other threads is irrelevant. // now you are just been obstinate... this is a silly argument... think about it for awhile you will understand that multiple threads all process instructions while the blocked thread waits ... this is a close analogy to how setTimeout works with an async function call. Not perfect but close... and most certainly not irrelevant.
declaring it irrelevant is like saying that you are the boss and what you say goes.
and since there are only two implementation of the javascript language that you can name... (actually 2.5 with deno) i doubt that it is a show stopper to add this function.
Or are you saying that setTimout is not part of the language (which it clearly has been from day one no matter what this particular subset definition states)...
If it is not part of the language does it just magically appear in all browsers and node in the exact same way with the same syntax and behavior?
It must be defined formally somewhere.... if not here then where?
I think i changed my mind about discussing this any further
This is a colossal waste of time.. You have not told me anything i did not already know and are not able to understand what i am proposing.
It’s part of the HTML spec, which is why browsers have it.
node implements it separately, where it does not have the same behavior - it returns a timer object instead of an integer, for example. I’m not sure how deno implements it - I’m assuming they match either browsers or node, but they’d be within their rights to make a third version too.
2 Likes
Some caveat of this proposal:
nodejs setTImeout return object with .unref() method
nice catch :)