Delayed queuing of spawn_local tasks
#2854
Conversation
crates/futures/src/queue.rs
Outdated
| front_tasks: RefCell<VecDeque<Rc<crate::task::Task>>>, | ||
| // We use a double-buffer approach to running tasks. Tasks initially enter the | ||
| // back_tasks which gets swapped to the front when we resume spinning. | ||
| back_tasks: RefCell<VecDeque<Rc<crate::task::Task>>>, |
There was a problem hiding this comment.
I'm not actually sure if it's necessary to have a distinction here with two deques. Could the new tasks actually always be enqueued for a future microtask tick? I think implementing everything in the same microtask tick was primarily done for convenience over anything else.
There was a problem hiding this comment.
I wasn't sure how common it was for tasks to immediately reschedule. I thought it could lead to a surprising number of ticks for some tasks to run to completion if rescheduling always waits for the next tick (compared to the current behaviour).
Note the test case actually tests for this, by requiring the Yield task to complete (on the same tick) before the newly scheduled task (on the next tick).
Re-reading the documentation of js Promise, which always schedules the callbacks of .then() asynchronously, delaying would be the choice, but besides the existing quirks of javascript, I can't think of a reason to do this.
There was a problem hiding this comment.
I think it's safe to always enqueue to a future tick because that's what JS promises do with .then and once you're using promises chances are that things will take awhile to complete and it'll be pretty rare to have an immediately enqueued piece of work anyway.
There was a problem hiding this comment.
Has been a bit more complicated to write a good test case, but I think I got it. The test case fails on main and succeeds with both approaches
|
The one failing check seems to be unrelated to the PR and more to the release of |
|
Could you either pin the wasmprinter version to the previous version or run the failing test suite with |
Fixes #2847
Tasks are now reliably scheduled to start running on the next tick reliably. Note that Tasks that later wake on the same tick as they are, still run immediately without this delay.