Draft: Futures module

[ranfdev]

Related issue: #935

I think there are currently too many timeout functions, with too many combinations of scheduling priority and scheduling precision (second, millisecond).

Instead of just moving every timeout function to a futures module, I've decided to redesign the API taking advantage of the Builder pattern and the IntoFuture trait.

API example:

c.block_on(async {
    sleep(Duration::from_millis(10)).await;
    sleep(Duration::from_secs(1))
        .priority(crate::PRIORITY_LOW)
        .precision(SchedulingPrecision::Seconds)
        .await;
});

I'm still looking if it's possible to redesign spawn and idle with the same mindset. I don't particularly like having spawn, spawn_local, spawn_local_with_priority, spawn_with_priority, spawn_within, spawn_within_with_priority, ...

[sdroege]

I'm still looking if it's possible to redesign spawn and idle with the same mindset. I don't particularly like having spawn, spawn_local, spawn_local_with_priority, spawn_with_priority, spawn_within, spawn_within_with_priority, ...

That sounds like a nice idea. You probably won't get around distinguishing spawn() and spawn_local() though because of the different trait bounds.

[sdroege]

Maybe the precision should be defined based on whether the Duration has fractional seconds or not? Or is that too implicit?

Otherwise maybe having a sleep(Duration) and sleep_seconds(u32) would be simpler API.

[ranfdev]

We can't make it implicit based on the choosen Duration, because the user could want to actually wait 2000 milliseconds precisely, and not 2 seconds roughly.

What about having the methods precision_seconds, precision_milliseconds, so that we can remove the public enum SchedulingPrecision?

[sdroege]

Good point. Yes that would also work

[ranfdev]

Thinking about it... In gtk adding a new enum for a specific function seems to be pretty normal. I think it fits adding an enum here as well

[sdroege]

This all needs docs