Drastically simplify with ideas from tokio

[alexcrichton]

This series of commits are the culmination of some discussions with @carllerche
about experiences in tokio and how they could be more generally applicable to
futures. The end result is a drastically simplified Future trait, simplified
interface to I/O, and a much more ergonomic method of implementing a future.

The two key insights which led to simplification was:

• There's no need for a schedule method if poll did the scheduling for you.
  That is, if poll returns NotReady then it's responsible for arranging the
  future's task to get notified.
• Next, it's more flexible to work with existing abstractions to not take a
  Task parameter, but instead use thread local storage for the current task.
  This enables reusing existing abstractions off the shelf as threading a Task
  parameter around isn't necessary.

When combined together, these end up having large ramifications across the
implementations of the event loop, futures, etc.

Simplified Future trait

The trait now looks like:

trait Future {
    type Item;
    type Error;
    fn poll(&mut self) -> Poll<Self::Item, Self::Error>;
}

As mentioned above, the schedule method has been removed as poll will do
that automatically. Additionally the Task argument has been removed as it's
now a piece of thread-local global state indicating what the current task is.
Finally, the 'static bounds have been removed entirely (more on this in a
moment).

Finally, with this definition, it means that the Future trait is #![no_std]
compatible! All core combinators and the trait itself can be used in the context
of only libcore. The scheduling (e.g. task module) of futures still requires
the standard library, but it is now easily split off into a separate layer if
needed.

Simplified I/O

In the spirit of poll automatically "scheduling" the current task to receive a
notification when it's ready to make progress, I/O now operates the same way.
When a read or write is performed and it returns "would block", the current
task is scheduled to receive a notification when the I/O operation is again
available.

This means that the futures-io abstraction of Stream<Item=Ready> is no longer
needed, and has now been removed. All I/O now works purely over the Read and
Write traits assuming that it will not block. Most of the I/O objects in
futures-io have been removed as the ones in the standard library can be used
instead. The futures abstractions here, however, for things like write_all etc
still exist (and operate over Read and Write).

This in turn greatly simplifies implementations of state machines as you
generally just perform the I/O as if it were going to succeed, and "would block"
is propagated as NotReady. The operation will then get automatically retried
when I/O is available again.

Removal of 'static

Another key improvement in this PR is the removal of the 'static bound from
the Future trait and its associated types. The insight here is that a
non-'static future, containing stack borrows, can be run like scoped threads.
That is, you can borrow data as long as you know the task completes before the
stack frame is popped.

The Loop::run method no longer requires the 'static bound and can be used to
execute futures which do not have the 'static lifetime.

[MarkusJais]

I like the changes. Simplification is good :-)

[carllerche]

👍 looks good to me.

[shepmaster]

as it's now a piece of thread-local global state indicating what the current task is.

Sorry for asking after it was merged and without being able to give a deep read of the code, but what about environments that don't have threads? The concepts of this library on a tiny microcontroller still make sense to me, even if I haven't had any opportunity to do anything with it.

[alexcrichton]

That's a good question! For microcontrollers they're probably using #![no_std] where the task module doesn't even exist, so there's no thread locals for the #![no_std] version of this crate.

The core assumption, however, is that there is some global state which indicates how to "block the current task" right now. That is, there must be some equivalent for task::park and TaskHandle::unpark.

For cases without threads this could just be implemented trivially with a global, so I don't think this excludes those situations (or at least that's our belief)