I think we have to avoid this behavior on Scala.js, or else it becomes impossible to run anything asynchronously, right? At least, assuming we end up with setImmediate for our execution context.

Some callback code in JS has to be run synchronously: e.g. when you handle a mouse or keyboard event.

Yes, I think that is a fairly straightforward change on Scala.js. The fact that all the test suites fail with this change on the JVM is somewhat concerning.

The issue was that unsafeRunSync was defined in terms of unsafeRunAsync. unsafeRunSync is relatively safe for small effects if the effect is run on the same thread because then the OneShot will be set by the time get is called so there will be no blocking. But if we introduce an asynchronous step at the beginning every time the current thread immediately proceeds to evaluate OneShot#get blocking and potentially starving the ZIO thread pool if the thread that was evaluating unsafeRunSync was one of the ones from the ZIO thread pool.

Just a thought: Why not use Promise.then() in Scala.js to schedule things instead of setImmediate.

That will actually guarantee that the callback scheduled will execute as soon as the current call stack is completed.

@tusharmath I think we need to do a subsequent PR where we look at all the options for how submitting an effect to the Executor on Scala.js should be interpreted but that should definitely be one of them.