Is there a migration guide somewhere? e.g. right off the bat with legacy code I'm getting that there's no futures::task::current
, or futures::Async
... I see that new futures only have one associated type, etc.
Hmm as I'm going through it, seems pretty straightforward...
But one thing I'm currently stuck on is it seems channels no longer have poll()
?
I also tried try_poll
but I'm getting an error that this doesn't exist either..
Looking at the docs, it seems to have a .try_recv
and .recv
function now.
hmmhmm... using that, do I then need to manually wake again? guess I'll try and see...
Wait - the docs at futures::channel::oneshot::Receiver - Rust say:
Does not schedule a task wakeup or have any other side effects.
Though I see Receiver
implements Future
, and this seems to compile:
if let Poll::Ready(value) = Receiver::poll(Pin::new(receiver), ctx) {
Not sure about this Pin
stuff though... or how do deal with cancellations (since that's a possible return type)
I've never actually worked with futures or async, so I'm pretty unknowledgable about this. I have done some multithreading though, so that's about all I can give.
Sorry for the inconvenience.
All good! My gut feeling as that this Receiver::poll(Pin...
is too bulky to be right. Gonna try sticking with try_recv
and manually waking
fwiw seems try_recv()
works and without manually waking... I guess returning Pending
somehow keeps the polling happening shrug
wouldn't cite this as something to really look at, but it seems to work
(just noticed that I need to clean up some stray comments and stuff - but don't want to link to master since this will almost definitely change in the, uhh, future)
Very early days... but it's cool to see a smiley face
You may have been running into this bug in rustc
's error messages.
Receiver
is Unpin
so you should be able to use something like let value = ready!(receiver.poll_unpin(cx))?;
to try reading from it from within your Future
implementation, (using FutureExt::poll_unpin
to avoid having to construct your own Pin
, and ready!
to early-return Pending
(which looks appropriate for your current implementation at first glance)).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.