Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Remove
MaybeDone
fromtuple::join
#74Remove
MaybeDone
fromtuple::join
#74Changes from all commits
be1d966
32a5233
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to instead do:
That way we can move the tuple fields into here basically in-place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm currently trying to figure out how to do this!
tuple: ($(#[pin] $F: $F,)*)
doesn't work becausepin_project
doesn't support pinning this way, like(#[pin] T, #[pin] S)
play
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yoshuawuyts, I got something!
It's on a second branch, here.
I took some inspiration from #84 to use the pinned futures inside a tuple(struct), and it kinda works.
We have some performance gain, but it's kinda negligible 😞 (especially thinking about the macro-heavy impl orientation)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I like the intermediate struct approach!
The reason why there's a small perf cost might be because you're using
ptr::read
there which ends up doing an extra copy? Instead I think if it's at all possible it might be worth attempting to perform a direct transmute? This might require adding a#[repr(transparent)]
to theFutures
struct so that the layout is guaranteed to be the same as the tuples it stores?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, I don't think
#[repr(transparent)] Futures
is possible,transparent
only allows one field to have a non-zero size, theFutures
have many.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oof, TIL :')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oook, it seems to me that we cannot transmute
(MaybeUninit<T>, MaybeUninit<U>)
to(T, U)
.I'm not sure why, but I guess it's the same underlying problem from rust-lang/rust#61956, so casting the tuples appears to be the best option so far
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Transmuting is not what you want here I think ?
This can be macro-ified using
$F
as the variable name: it won't even shadow the type names because that's two different namespaces (let usize: usize = 4_usize;
is valid)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming the
t
is owned, this should not do any copy anywhereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ohh, thank you for pointing it out! I'll try that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PollArray is usable here