use FuturesUnordered instead of embassy_futures::join

[tommasoclini]

Hi,

I noticed that to run multiple things at once embassy_futures::join is being used, I have a similar use case where I have replaced it with FuturesUnordered from futures-rs and this avoids polling every future every time, kind of like if they were separate tasks(I did this after noticing that all of my futures were being pulled like 1000 times per second).

It uses an Arc backed linked list, but allocations are made only when setting up the futures, not while running them. I have a fork of futures-rs in my profile that optionally uses portable-atomic and portable-atomic-util types, so archs without atomics are not a problem.

I know it is a bit experimental, but I wanted to know if you would like to give it a try, right now I don't have hardware to test on, but if you do want to try it I'll modify an example for you to test it.

[HaoboGu]

I'm wondering that does it require alloc? If not, I think adding it to embassy_futures would be great?

[tommasoclini]

I'm wondering that does it require alloc? If not, I think adding it to embassy_futures would be great?

It does require alloc, but in your use case it would be a one time allocation at the start of the program.

[tommasoclini]

You can avoid allocating the entire futures by using pinned mutable references instead of moving them when pushing them to FuturesUnordered.

[HaoboGu]

That's great

[tommasoclini]

In 2-3 hours I'll edit an existing example so that you can test it, what example should I edit?

[HaoboGu]

I prefer to keep using embassy-futures, would you like drafting a PR in embassy project?

[tommasoclini]

It doesn't make a lot of sense, futures-rs is already no-std, why would something need to be duplicated in two different crates? What worries you about using futures-rs?

[HaoboGu]

Avoiding polling every future every time is a good feature, I don't think it's duplicate, and I prefer to use methods provided by upstream which is already used, for example official futures-rs or embassy-futures. I don't want to add an extra dependency.

[tommasoclini]

Sorry, I thought you meant you don't want to use futures-rs at all, if you don't want to use my fork I completely understand that, right now I have a PR that's been open for a month in futures-rs, but they won't answer or help me 🥲.

rust-lang/futures-rs#3007

[HaoboGu]

Yeah, RMK already has futures as its dependency, so if this can be added to futures-rs or embassy-futures, I'd be happy to use it.

For the failure here, I think you should enable critical-section feature for portable-atomic dep in your PR.

[tommasoclini]

Hi, sorry for the late response, if I add portable-atomic as a dependency in the no-std test runner I get a bunch of errors, I had tried that before.

[tommasoclini]

@HaoboGu it might be about to get merged, the changes have been approved.

[tommasoclini]

@HaoboGu I finally got it merged

[HaoboGu]

Great! I'm looking forward to adding it when it's released! Thanks for your effort!

[tommasoclini]

@HaoboGu It got released, should I make a fork and edit an existing example? I have no hardware to test it on, so tell me what I should do.