Skip to content

Provide TestHarness to make testing future / combinator implementations easier. #598

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

Closed
wants to merge 6 commits into from
Closed

Conversation

carllerche
Copy link
Member

Depends on #597

This PR adds a new type: executor::TestHarness. This type is very similar to Spawn but is intended to be used from the context of tests. As such, it provides a slightly different API. While this functionality could be provided directly by Spawn, Spawn already has a fairly busy API surface and some of the capabilities of TestHarness doen't make as much sense when used in "real code".

This PR only provides the ability to wrap a Future for now, but at a later time, support for Stream and Sink can be added.

The idea would be for TestHarness<impl Stream> to provide:

  • impl Iterator
  • poll_next(&mut self) -> Poll<Option<Self::Item>, Self::Error>
  • wait_next_timeout(&mut self) -> Result<Option<Self::Item>, TimeoutError<Self::Error>>

And for TestHarness<impl Sink>:

  • try_send(&mut self, item: T::SinkItem) -> StartSend<T::SinkItem, T::SinkError>
  • send_timeout(&mut self, item: T::SinkItem) -> Result<(), SendTimeoutError<T::SinkItem, T::SinkError>>

This renames an internal type away from deprecated terminology.
This change avoids the Arc allocation for each blocking call as well as
eliminates the need to perform the Arc ref count increment if
unnecessary.
Unfortunately, using an atomic requires a final atomic CAS within the
"wakeup" mutex. This means we cannot use the thread park / unpark
helpers from std.

This change increases a single threaded "yield" benchmark by almost 40%.
This wrapper is similar to `Spawn` but is intended to be used from
context of tests. As such, it provides a slightly different API as well
as the ability to introspect task notifications.
@alexcrichton
Copy link
Member

Hm I'd imagine that if we want to make futures-based tests easier to write we could probably go farther? Maybe we could try to collect test-related helpers in a futures-test crate or something like that? (avoid exposing more surface area here)

@carllerche carllerche closed this Nov 21, 2017
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.

2 participants