Migration from futures 0.1 to 0.3?

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 https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.16/futures/channel/oneshot/struct.Receiver.html 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.

1 Like

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 :slight_smile:

(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 :smiley:

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)).

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.