Add future::timeout()

[ghost]

cc #18

[skade]

Can we somehow mark interfaces as experimental?

[ghost]

We could do this:

[skade]

Sounds good! Maybe with a config flag to avoid them?

[ghost]

You mean feature flag?

[skade]

Ah, right - yes, a feature flag.

[ghost]

I feel reluctant to put stuff behind feature flags at this point since we're releasing a preview version with plenty of time till 1.0 release, and can do breaking changes before then. Wdyt?

[skade]

You are right, if we are reasonably sure, we can do it this way.

[kpp]

Does it mean that in case of a CPU-bound future that is blocking the current thread you will never try to poll the timer and return TimeoutError?

[skade]

/cc @stjepang

[ghost]

@kpp That's a good point - do you think we should check for timeout before polling the future?

I worry a bit that this would add overhead to futures that are quick to poll or immediately ready. And if the future is CPU-bound and takes a really long time, we can still get stuck if the timeout occurs while that future is running.

All things considered, I think I prefer the current behavior. Wdyt?

[kpp]

All things considered, I think I prefer the current behavior.

Yep... I don't see a better solution for this.

Still I would rewrite the current implementation as f.select(Delay::new(dur))... ;)

[kpp]

Also notice how this code can be reduced: #113

[kpp]

BTW what's the difference between future::timeout() and io::timeout()?

[skade]

@kpp io::timeout takes the io::Error of the I/O Operation and forwards it, and itself errors as io::Error with kind TimeoutError. future::timeout does none of that and instead wraps the underlying operation. If the timed out operation returns a result, future::timeout returns Result<Result<...>>, while io::timeout only returns io::Result<...>.

[ghost]

I put this function behind the new unstable feature flag.

[yoshuawuyts]

Looks great! -- not sure we need the unstable feature here, but not opposed to being cautious either (: -- let's go ahead and merge!!