-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Provide getters of data and vtable pointer for RawWaker
?
#87021
Comments
We discussed this during today's triage meeting, and the async foundations WG is generally +1 on this idea. cc/ @rust-lang/libs what do you think the right steps here should be? |
It makes sense to me, but it's more precisely a question for @rust-lang/libs-api. |
wg-async-foundations discussed and we're generally supportive of the idea, but agreed it's the libs API team who owns this. |
We discussed this in today's @rust-lang/libs-api meeting. We're in favor of adding these methods, as inverses of |
@rustbot label +AsyncAwait-Triaged |
Implement `RawWaker` and `Waker` getters for underlying pointers implement rust-lang#87021 New APIs: - `RawWaker::data(&self) -> *const ()` - `RawWaker::vtable(&self) -> &'static RawWakerVTable` - ~`Waker::as_raw_waker(&self) -> &RawWaker`~ `Waker::as_raw(&self) -> &RawWaker` This third one is an auxiliary function to make the two APIs above more useful. Since we can only get `&Waker` in `Future::poll`, without this, we need to `transmute` it into `&RawWaker` (relying on `repr(transparent)`) in order to access its data/vtable pointers. ~Not sure if it should be named `as_raw` or `as_raw_waker`. Seems we always use `as_<something-raw>` instead of just `as_raw`. But `as_raw_waker` seems not quite consistent with `Waker::from_raw`.~ As suggested in rust-lang#91828 (comment), use `as_raw`.
Implement `RawWaker` and `Waker` getters for underlying pointers implement rust-lang#87021 New APIs: - `RawWaker::data(&self) -> *const ()` - `RawWaker::vtable(&self) -> &'static RawWakerVTable` - ~`Waker::as_raw_waker(&self) -> &RawWaker`~ `Waker::as_raw(&self) -> &RawWaker` This third one is an auxiliary function to make the two APIs above more useful. Since we can only get `&Waker` in `Future::poll`, without this, we need to `transmute` it into `&RawWaker` (relying on `repr(transparent)`) in order to access its data/vtable pointers. ~Not sure if it should be named `as_raw` or `as_raw_waker`. Seems we always use `as_<something-raw>` instead of just `as_raw`. But `as_raw_waker` seems not quite consistent with `Waker::from_raw`.~ As suggested in rust-lang#91828 (comment), use `as_raw`.
Implement `RawWaker` and `Waker` getters for underlying pointers implement rust-lang#87021 New APIs: - `RawWaker::data(&self) -> *const ()` - `RawWaker::vtable(&self) -> &'static RawWakerVTable` - ~`Waker::as_raw_waker(&self) -> &RawWaker`~ `Waker::as_raw(&self) -> &RawWaker` This third one is an auxiliary function to make the two APIs above more useful. Since we can only get `&Waker` in `Future::poll`, without this, we need to `transmute` it into `&RawWaker` (relying on `repr(transparent)`) in order to access its data/vtable pointers. ~Not sure if it should be named `as_raw` or `as_raw_waker`. Seems we always use `as_<something-raw>` instead of just `as_raw`. But `as_raw_waker` seems not quite consistent with `Waker::from_raw`.~ As suggested in rust-lang#91828 (comment), use `as_raw`.
Implement `RawWaker` and `Waker` getters for underlying pointers implement rust-lang#87021 New APIs: - `RawWaker::data(&self) -> *const ()` - `RawWaker::vtable(&self) -> &'static RawWakerVTable` - ~`Waker::as_raw_waker(&self) -> &RawWaker`~ `Waker::as_raw(&self) -> &RawWaker` This third one is an auxiliary function to make the two APIs above more useful. Since we can only get `&Waker` in `Future::poll`, without this, we need to `transmute` it into `&RawWaker` (relying on `repr(transparent)`) in order to access its data/vtable pointers. ~Not sure if it should be named `as_raw` or `as_raw_waker`. Seems we always use `as_<something-raw>` instead of just `as_raw`. But `as_raw_waker` seems not quite consistent with `Waker::from_raw`.~ As suggested in rust-lang#91828 (comment), use `as_raw`.
I was surprised to see that |
Typically, we can only get |
I was tried to implement a single threaded async executor on the stable branch and just got bitten by this issue, which forced me to use a global variable to store the future-specific data when it got suspended. |
Closing this in favor of the tracking issue #96992. |
…ng_issue_number, r=workingjubilee fix `waker_getters` tracking issue number The feature currently links to the closed issue rust-lang#87021. Make it link to the tracking issue rust-lang#96992 instead.
Rollup merge of rust-lang#118873 - lukas-code:fix_waker_getter_tracking_issue_number, r=workingjubilee fix `waker_getters` tracking issue number The feature currently links to the closed issue rust-lang#87021. Make it link to the tracking issue rust-lang#96992 instead.
Docs of
std::task::RawWaker
:We said it consists of two pointer, but doesn't enforce its layout by
repr
, nor provide methods to get data and vtable pointer from a constructedRawWaker
. So it impossible to destruct aRawWaker
even withtransmute
, since the layout is unknown, which makdes it difficult to passRawWaker
orWaker
across FFI boundary.Note that
Waker
hasrepr(transparent)
on it so it's able totransmute
into aRawWaker
. But it barely does anything since we can do nothing with aRawWaker
. I'm confusing about why there is arepr(transparent)
struct to an blackbox struct without any methods.If it's intended to NOT stabilizing the layout of
std::task::RawWaker
. I think we should at least provide methods likefn data(&self) -> *mut ()
andfn vtable(&self) -> &'static RawWakerVTable
to do the inverse ofRawWaker::new
, which can be used to destruct it to cross FFI boundary.The text was updated successfully, but these errors were encountered: