Skip to content
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

protocols/kad: Fix tests #1320

Merged
merged 13 commits into from
Nov 28, 2019
Merged

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented Nov 25, 2019

This pull request adjusts the Kademlia tests to the stable future refactoring.

(+ 2 minor fixes in noise and mdns)

@mxinden mxinden requested a review from romanb November 25, 2019 12:37
Async::NotReady => break,
}
}
block_on(async move {
Copy link
Member Author

@mxinden mxinden Nov 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the test easier to understand, when we first poll all swarms except the first one, giving them a chance to make progress, and then check whether the first swarm has bootstrapped successfully.

What do you think @romanb? I would apply the same pattern to the similar tests below in case people are in favor of this style.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm generally OK with it, though I don't find it simpler personally, but it seems to be semantically equivalent (i.e. each swarm is polled until pending or the expected result appears). However, I have two small comments:

  1. Is the 'outer loop label necessary (i.e. why not return as before)?
  2. If I see it correctly, then while all swarms are "not ready" / "pending" (e.g. waiting for I/O), this variant seems to enter a "busy loop", not yielding control of the thread to do other useful things meanwhile. While this probably doesn't matter much especially since the tests use the MemoryTransport, I still find it cleaner to yield the thread when all swarms are pending.

Copy link
Contributor

@romanb romanb Nov 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another small difference to the previous code seems to be that this version does not fail the test if any other swarm besides the first produces a BootstrapResult (which would naturally be incorrect and unexpected). Again, this may not be important, but it is a difference.

@tomaka
Copy link
Member

tomaka commented Nov 25, 2019

I'm not a fan of using poll_fn and adding // TODO: refactor.
It shouldn't be hard to use async/await properly here.

@mxinden
Copy link
Member Author

mxinden commented Nov 25, 2019

@tomaka see #1320 (comment). I would like to get your input on the style before I touch all following tests and remove their poll_fn and TODOs.

@mxinden
Copy link
Member Author

mxinden commented Nov 27, 2019

I went for the poll_fn approach for the following reasons:

  • Least intrusive, easiest to review.

  • Using an async closure with now_or_never and pending! (to not enter a busy loop) seems to defeat the purpose. Alternatively awaiting each swarm individually via a FutureUnordered introduces too much overhead having to synchronize access to shared data structures.

@tomaka @romanb let me know what you think.

@mxinden mxinden marked this pull request as ready for review November 27, 2019 11:04
@tomaka
Copy link
Member

tomaka commented Nov 28, 2019

Could you rebase or merge the latest stable-futures?

// Polling with an instant beyond the deadline for the next run
// is guaranteed to run the job, without the job needing to poll the `Delay`
// and thus without needing to run `poll` in the context of a task
// for testing purposes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment does no longer reflect reality and should be removed, as the test is now always run in the context of a task (necessarily, because poll() now takes the task context as a parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for missing that, thanks.

// Polling with an instant beyond the deadline for the next run
// is guaranteed to run the job, without the job needing to poll the `Delay`
// and thus without needing to run `poll` in the context of a task
// for testing purposes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just like the other case, this comment should now be removed.

@mxinden
Copy link
Member Author

mxinden commented Nov 28, 2019

@romanb could you take another look?

@mxinden mxinden merged commit 26f58d2 into libp2p:stable-futures Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants