Stabilize "Deno.sleepSync" API

[bartlomieju]

It's been unstable long enough, there's really not much to it.

It would allow to refactor and remove some code from deno_web extension, namely TimerPermissions trait wouldn't need to have check_unstable method.

[lucacasonato]

@ry might have objections here. I know he didn't really like the API back when.

[lucacasonato]

Also, we should check that the same functionality isn't already possible with just Atomics. Possibly the same functionality is available with:

const sab = new SharedArrayBuffer(1024);
const int32 = new Int32Array(sab);
const timeout = 1000; // 1s
Atomics.wait(int32, 0, 0, timeout);

[dsherret]

Apparently the issue with Atomics.wait is that it doesn't currently work in the main worker context?

We discussed this super briefly in the design meeting and if there's a way we could provide a helper in deno.land/std for doing this with Atomics.wait, we think that would be preferable.

I do really think we should have a way to sleep synchronously though as it can provide a more accurate sleep mechanism for some non-web server applications (ex. when using hardware).

[ry]

sleepSync has no utility - it's very easy to misuse - let's remove it not stabilize it.

[dsherret]

sleepSync has no utility

...for web servers

[trgwii]

It's very trivial to write a sleepSync that does this:

const end = Date.now() + 1_000;
while (Date.now() < end);

But it's fairly nontrivial to implement a sleepSync that works in all contexts and doesn't busyloop the CPU, so seems fairly reasonable to have Deno.sleepSync imo (with a big JSDoc warning)