maitake: Schedule::current_task method
#277
Labels
Comments
hawkw
added
kind/enhancement
hawkw
added a commit
that referenced
this issue
Jul 30, 2022
This adds an initial implementation of a `Schedule::current_task` method for cloning the currently-polled task. This implementation is somewhat inefficient, as it has to perform an additional ref count clone/drop cycle on every poll. This is unfortunately necessary because the current task variable is not unset until the `TaskRef::poll` method returns, and that method can drop the task, so we have to keep the task alive as long as it's accessible through the scheduler (or else we risk handing out `TaskRef`s pointed at deallocated tasks). We can probably improve this by removing the unnecessary ref clone/drop cycle, if we refactored how polling works a bit. If the scheduler unset the current task variable _before_ a task is dropped, we wouldn't need to clone the task before storing it in the current task variable...but, this implementation works for now. Closes #277
hawkw
added a commit
that referenced
this issue
Jul 31, 2022
This adds an initial implementation of a `Schedule::current_task` method for cloning the currently-polled task. This implementation is somewhat inefficient, as it has to perform an additional ref count clone/drop cycle on every poll. This is unfortunately necessary because the current task variable is not unset until the `TaskRef::poll` method returns, and that method can drop the task, so we have to keep the task alive as long as it's accessible through the scheduler (or else we risk handing out `TaskRef`s pointed at deallocated tasks). We can probably improve this by removing the unnecessary ref clone/drop cycle, if we refactored how polling works a bit. If the scheduler unset the current task variable _before_ a task is dropped, we wouldn't need to clone the task before storing it in the current task variable...but, this implementation works for now. Closes #277
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be nice to have a function for getting the current task. This can be used by leaf futures if they want to self-wake, access information about what task they're being polled from, such as for debugging (see #265 and #267) , or forcibly cancel the current task (see #264).
maitakeitself can't implement an "ambiently available"task::current()function, because it doesn't know about "locality"1. But, we can add a method to theSchedulertypes for accessing the task that scheduler is currently polling. Then, the OS can use this to implement atask::current()by finding the current core's scheduler (or picking the global one if single-core).I imagine this would have a signature like
We would probably have to store the task ptr in an
AtomicPointerin the scheduler, and load that and that into aTaskRefif someone wants it.Footnotes
Are we single-core, and there's a single global scheduler? Or are we multi-core, and each core has its own scheduler? And if so, how do I access the scheduler for the current core? Those are all OS-level concerns that
maitakecan't handle. ↩The text was updated successfully, but these errors were encountered: