(#5) Previously, awaiting drivers while recovering from a pause blocked
unnecessarily, since the slowest child to receive that last element
would block the whole Producer in _attach. It seems inevitable that
that responsibility would go back to the driver itself, for which
get_iterator_edge already resets if it is null. To avoid an indirect
$this reference from calling awaitify from the driver (since the
awaitify body contains references to $this), the driver?Awaitable is
wrapped and _attach delegates responsibility for restarting the
iterator to get_iterator_edge.
This solution isn't the best, since it still relies on the iffy practice
of returning control to the synchronous calling scope of an async
block via await \HH\Asio\later(). So far, it hasn't failed in
practice. However, I am wary of relying on this.
(#5) Previously, awaiting drivers while recovering from a pause blocked unnecessarily, since the slowest child to receive that last element would block the whole
Producer
in_attach
. It seems inevitable that that responsibility would go back to the driver itself, for whichget_iterator_edge
already resets if it is null. To avoid an indirect$this
reference from callingawaitify
from the driver (since theawaitify
body contains references to$this
), the driver?Awaitable is wrapped and_attach
delegates responsibility for restarting the iterator toget_iterator_edge
.This solution isn't the best, since it still relies on the iffy practice of returning control to the synchronous calling scope of an
async
block viaawait \HH\Asio\later()
. So far, it hasn't failed in practice. However, I am wary of relying on this.