Main-Thread-Scheduling
github.com
Main-Thread-Scheduling
1–10 of 26 posts
Re: Main-Thread-Scheduling
#2The author here. Just opened HN and saw that my library is on the front page . If you have any questions, I can answer them.
Re: Main-Thread-Scheduling
#3How is this able to pause work, given that the work is already executing on the main thread (and I assume you don't need to rewrite your code to explicity give up control at various points)?
Re: Main-Thread-Scheduling
#4The author here. Just opened HN and saw that my library is on the front page . If you have any questions, I can answer them.
How does this differ from cooperative multi tasking?
Re: Main-Thread-Scheduling
#5How is this able to pause work, given that the work is already executing on the main thread (and I assume you don't need to rewrite your code to explicity give up control at various points)?
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.
Re: Main-Thread-Scheduling
#6How is this able to pause work, given that the work is already executing on the main thread (and I assume you don't need to rewrite your code to explicity give up control at various points)?
[deleted]
Re: Main-Thread-Scheduling
#7I 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 allocated, especially if you're in a loop doing a lot of work.
Re: Main-Thread-Scheduling
#8The author here. Just opened HN and saw that my library is on the front page . If you have any questions, I can answer them.
How does this differ from cooperative multi tasking?
If I'm reading this correctly, this is a library for use within a browser, in which case the answer is that this makes it easier to live within the constraints of the browser, which has arguably the strangest "multitasking" support anywhere, what with all the constraints it had to satisfy to be added in to an architecture already 15 years old at that point.
Re: Main-Thread-Scheduling
#9Earlier quoted context omitted.
How does this differ from cooperative multi tasking?
If I'm reading this correctly, this is a library for use within a browser, in which case the answer is that this makes it easier to live within the constraints of the browser, which has arguably the strangest "multitasking" support anywhere, what with all the constraints it had to satisfy to be added in to an architecture already 15 years old at that point.
Yeah, that sums it up. The library tries to use the single thread the browser UI is running on and just not freeze it.
Re: Main-Thread-Scheduling
#10How is this able to pause work, given that the work is already executing on the main thread (and I assume you don't need to rewrite your code to explicity give up control at various points)?
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.