Alex Crichton a1da85a24b Defer future execution to the next event loop tick ... Previously whenever a future readiness notification came in we would immediately start polling a future. This ends up having two downsides, however: * First, the stack depth may run a risk of getting blown. There's no recursion limit to defer execution to later, which means that if futures are always ready we'll keep making the stack deeper. * Second, and more worrisome in the near term, apparently future adapaters in the `futures` crate (namely the unsync oneshot channel) doesn't actually work if you immediately poll on readiness. This may or may not be a bug in the `futures` crate but it's good to fix it here anyway. As a result whenever a future is ready to get polled again we defer its polling to the next turn of the event loop. This should ensure that the current call stack is always drained and we're effectively enqueueing the future to be polled in the near future.		2018-10-23 07:12:54 -07:00
..
tests.rs	Defer future execution to the next event loop tick	2018-10-23 07:12:54 -07:00