uvio's read_stream() may not trigger task scheduling

[klutzy]

std::rt::uv::uvio::read_stream() calls StreamWatcher::read_start() with on_read callback containing scheduler.resume_blocked_task_immediately(task_cell.take());.

However, in some bad cases, read_start() does not call on_read, thus the task hangs.

Here is excerpt from libuv/src/win/stream.c:

int uv_read_start(uv_stream_t* handle, uv_alloc_cb alloc_cb,
    uv_read_cb read_cb) {
...
  if (handle->flags & UV_HANDLE_READING) {
    fprintf(stderr, "UV_HANDLE_READING. return UV_EALREADY");
    return UV_EALREADY;
  }

  if (!(handle->flags & UV_HANDLE_READABLE)) {
    fprintf(stderr, "!UV_HANDLE_READABLE. return UV_ENOTCONN");
    return UV_ENOTCONN;
  }

...
      err = uv_tcp_read_start((uv_tcp_t*)handle, alloc_cb, read_cb);
...
}

This blocks #8811's read_eof_twice_ip4() and read_eof_twice_ip6() tests on win32: second stream.read() triggers UV_HANDLE_READABLE condition.
The problem does not occur on unix since there is no check equivalent to UV_HANDLE_READABLE.

[klutzy]

We currently ignore return value from uvll::read_start(). If this function returns != 0, the read_cb may not be called. (I'm not sure if it is promised by API design, since libuv API doesn't explain return value at all.)

[klutzy]

I guessed uv_read_start() == 0 indicates cb_read callback is called, but it seems not for one case: On win32, uv_tty_read_start() (called by uv_read_start) can return 0 without callback trigger.

[brson]

Let's handle the return value correctly.

[klutzy]

@brson I have a dirty-stashed patch which calls read_cb by hand when nonzero comes. This solves some cases, but I'm still unclear if this is the best. What about uv_tty_read_start() mentioned above?

[klutzy]

I now understand that return value really indicates whether it is correctly registered to event pool or not.

[klutzy]

std::rt::uv::net::StreamWatcher::write has similar issue: it assert_eq!s that return value is zero, but assertion failes for std::rt::io::net::tcp::write_close_ip* tests on win32.

[alexcrichton]

This was closed by #9721