Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Main-Thread-Scheduling

github.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Main-Thread-Scheduling

#11

Post by astoilkov »

bastawhiz wrote: post #7

I really like this. This feels like what the native APIs would look like if Promises existed in the 90s. One thing that might be improved is removing the `Promise.resolve()` that `yieldOrContinue` returns when it is not time to yield. Awaiting non-Promises is totally fine: you just get that value back (the `await` does nothing). Avoiding constructing a resolved promise can help reduce the number of objects that get a…

It's done — https://github.com/astoilkov/main-thread-scheduling/commit/0.... Thanks.

A little thing but a great improvement. I'm now wondering why I did that.

Re: Main-Thread-Scheduling

#12

Post by jillesvangurp »

I've done some browser applications using kotlin-js. One of the nice things with kotlin-js is that you can use co-routines. That's a nice upgrade over of promises or even async await in typescript. And you can easily await javascript promises in kotlin (extension function) or deal with javascript code that expects a promise. Co-routines basically gives you structured concurrency, a bit more sane error handling with this, and a few more things. Javascript and typescript are a bit bare bones with this.

And of course in a browser, everything is basically happening asynchronously. So, there are a lot of places where co-routines can be useful. And you can just spin up stuff with launch {} as well and have things running in the background. Nice with web sockets for example.

Re: Main-Thread-Scheduling

#13

Post by cryptonector »

astoilkov wrote: post #10
bastawhiz wrote: post #5

Earlier quoted context omitted.

You await the `yieldOrContinue` function. `yieldOrContinue` returns a promise that resolves when your code should resume running. Your work will only be paused at places that you explicitly await the provided functions, so yes, you do need to explicitly give up control.

Yes, that's it. You choose where to pause/resume work and place the calls to `yieldOrContinue` there.

The only gotcha is that you have to choose wisely. It's not a bad thing though. This is really cooperative multitasking all over again.

Re: Main-Thread-Scheduling

#14

Post by rictic »

astoilkov wrote: post #2

The author here. Just opened HN and saw that my library is on the front page . If you have any questions, I can answer them.

Have you benchmarked the overhead of awaiting? I believe that in doing so you yield to the microtask queue and then your function has to be scheduled and run again. You could compare

        await yieldOrContinue('user-visible');
        doSomeWork();
against

        if (isTimeToYield('user-visible')) {
            await yieldControl('user-visible');
        }
        doSomeWork();
A few years back when I measured it on a fast laptop the cost was ~1µs to do `await 0;`

Re: Main-Thread-Scheduling

#15

Post by esprehn »

cryptonector wrote: post #13
astoilkov wrote: post #10

Earlier quoted context omitted.

Yes, that's it. You choose where to pause/resume work and place the calls to `yieldOrContinue` there.

The only gotcha is that you have to choose wisely. It's not a bad thing though. This is really cooperative multitasking all over again.

Pretty much, which is how browsers work in general with the single thread (ex. The html parser yields after a certain number of tokens or if user input is waiting).

React's concurrent mode is the same thing as well.

Re: Main-Thread-Scheduling

#16

Post by rixtox »

astoilkov wrote: post #11
bastawhiz wrote: post #7

I really like this. This feels like what the native APIs would look like if Promises existed in the 90s. One thing that might be improved is removing the `Promise.resolve()` that `yieldOrContinue` returns when it is not time to yield. Awaiting non-Promises is totally fine: you just get that value back (the `await` does nothing). Avoiding constructing a resolved promise can help reduce the number of objects that get a…

It's done — https://github.com/astoilkov/main-thread-scheduling/commit/0... . Thanks. A little thing but a great improvement. I'm now wondering why I did that.

You should do some measurement before calling it an improvement. If you read the ECMAScript standard[1] or this blog post from V8[2] about the inner workings of the `await` keyword, you would know even if you `await` a non-Promise value, it would still create a new Promise and put the suspended routine onto the microtask queue. So the change you made won't make a difference.

Besides, there is a JavaScript language feature that can give you finer control on routine suspension and resumption, decoupled from any of the microtask or macrotask queue. It's called the generator function. There are some good coroutine libraries based on generator functions, e.g. co.js[3] and redux-saga[4]. You can easily make something similar that can resume the suspended routine according to your scheduling policy that prioritize main thread rendering.

[1]: https://tc39.es/ecma262/#sec-promise-executor [2]: https://v8.dev/blog/fast-async#await-under-the-hood [3]: https://github.com/tj/co [4]: https://redux-saga.js.org

Re: Main-Thread-Scheduling

#17

Post by dnmllr_ »

astoilkov wrote: post #2

The author here. Just opened HN and saw that my library is on the front page . If you have any questions, I can answer them.

Hi, forgive me if I missed it, I just briefly browsed the repo. Does the library itself handle cancellation, or would user code be responsible for that?

Re: Main-Thread-Scheduling

#20

Post by sroussey »

jillesvangurp wrote: post #12

I've done some browser applications using kotlin-js. One of the nice things with kotlin-js is that you can use co-routines. That's a nice upgrade over of promises or even async await in typescript. And you can easily await javascript promises in kotlin (extension function) or deal with javascript code that expects a promise. Co-routines basically gives you structured concurrency, a bit more sane error handling with t…

What primitives does kotlin-js use? Promises or generators?
Post reply on HN