Feature: Provide getters of data and vtable pointer for RawWaker?
#87021
Comments
GuillaumeGomez
added
the
C-feature-request
|
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. |
cuviper
added
the
T-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. |
yaahc
added
the
I-libs-api-nominated
|
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 |
rustbot
added
the
AsyncAwait-Triaged
m-ou-se
removed
I-libs-api-nominated
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 aRawWakereven withtransmute, since the layout is unknown, which makdes it difficult to passRawWakerorWakeracross FFI boundary.Note that
Wakerhasrepr(transparent)on it so it's able totransmuteinto 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 RawWakerVTableto 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: