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.

2 Likes

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.