libuv和uv

libuv和uv_try_write：为什么有多个缓冲区？(libuv and uv_try_write: why multiple buffers?)

考虑uv_try_write的文档（同样适用于uv_write和uv_write2 ）。 声明是：

int uv_try_write(uv_stream_t* handle, const uv_buf_t bufs[], unsigned int nbufs)

其中uv_buf_t是至少包含以下字段的数据结构：

char* uv_buf_t.base size_t uv_buf_t.len

我很确定我在这里遗漏了一些东西。

一个人应该提交多个uv_buf_t结构而不是更大的结构的原因是什么？ uv_buf_t ，如果我有100个char要写出来，为什么我要提交10 uv_buf_t包含每10个char的uv_buf_t而不是包含100个char的uv_buf_t ？

这样一个选择有意义的现实世界的例子会很有帮助，因为我在阅读文档时无法弄清楚它。

Consider the documentation of uv_try_write (the same applies for uv_write and uv_write2 as well). The declaration is:

int uv_try_write(uv_stream_t* handle, const uv_buf_t bufs[], unsigned int nbufs)

Where uv_buf_t is a data structure that has at least the following fields:

char* uv_buf_t.base size_t uv_buf_t.len

I'm quite sure I'm missing something here.

What's the reason for which one should submit more than one uv_buf_t structure instead of a bigger one? In other terms, if I have 100 char to write out, why should I submit 10 uv_buf_t containing each 10 char instead of a uv_buf_t containing 100 char?

It would be helpful a real world example in which such a choice makes sense, for I can't figure out it while reading the documentation.

最满意答案

大多数应用程序可能使用单个应用程序，但由于writev是我们在try变体中公开它的东西。 想象一个应用程序，它充当代理，并在多个数据包中获取数据，然后需要中继。 一次性检测属于同一数据包的所有缓冲区将系统调用限制为1，而不是为所有缓冲区分配空间，然后复制内容只是为了调用write 。

您可以在此处详细了解该方法： https ： //en.wikipedia.org/wiki/Vectored_I/O

Most applications probably use a single one, but since writev is a thing we expose it in the try variant as well. Imagine an application which behaves as a proxy, and gets data in multiple packets which it then needs to relay. Sensing all buffers belonging to the same packet in a single go limits the syscalls to 1, instead of having to allocate space for all buffers, then copying over the content just to call write.

You can read more about the approach here: https://en.wikipedia.org/wiki/Vectored_I/O