uv_read() with exact size for streams #4703

You can control how much data to read by allocating that space in uv_alloc_cb.

Once you read that you can uv_read_stop so it no longer continues reading.

Rinse and repeat.

Once you read that you can uv_read_stop so it no longer continues reading.

Nice, looks like this is what I need. What happens if the client keeps sending data while there is no read? If I called uv_read_start then eventually uv_read_stop, would the stream be back in the same state as if uv_read_start was never called?

I assume something like this is the way to do a "sized read":

typedef struct {
    char* data;
    uint32_t off;
    uint32_t max;
    uv_read_cb cb;
} readall_t;

void readall__alloc(uv_handle_t* handle, size_t unused, uv_buf_t* buf) {
    readall_t* r = (readall_t*) uv_handle_get_data(handle);
    buf->base = r->data + r->off;
    buf->len = r->max - r->off;
}

void readall__read(uv_stream_t* client, ssize_t nread, const uv_buf_t* unused) {
    readall_t* r = (readall_t*) uv_handle_get_data((uv_handle_t*) client);

    if (nread > 0) {
        r->off += nread;

        if (r->off == r->max) {
            uv_read_stop(client);
            uv_buf_t buf = uv_buf_init(r->data, r->max);
            r->cb(client, r->max, &buf);
        }
    }
    else if (nread < 0) {
        uv_read_stop(client);
        uv_buf_t buf = uv_buf_init(NULL, 0);
        r->cb(client, nread, &buf);
    }
}

void readall__begin(uv_stream_t* stream, readall_t* r) {
    uv_handle_set_data((uv_handle_t*) stream, r);
    uv_read_start(stream, readall__alloc, readall__read);
}

You don't need to call the callback yourself, libuv will.

You also need to account for the case in which you read less data than the expected.

As for what happens when not reading, the kernel will buffer the data up to a point, after which it will start discarding it.

This kind of question seems to come up all the time. Indeed, @saghul, you yourself started a project ten years ago to change the API to something like uv_read in #192 (google groups discussion).

Here, I want to express a big +1 on this proposal. For me there are two distinct advantages:

1. Not having to call uv_read_stop in the callback (and consequently no more questions if this is ok)
2. Not having to supply a uv_alloc_cb to uv_read_start (and consequently fewer questions around this as well)

Indeed, with the current API, under straight-forward usage we reallocate and copy upon each read request, which for my use case is hard to avoid.

I understand that the disadvantage of this proposed uv_read API is that one has to allocate even before the first data has arrived. However, this is a tradeoff I am willing to make.

How hard would it be to offer uv_read on uv_stream_t alongside the current uv_read_start? Would a contribution here be welcome?