考虑 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
结构而不是一个更大结构?
换句话说,如果我有 100 个 char
要写出来,为什么我应该提交 10 个 uv_buf_t
包含每 10 个 char
而不是一个 uv_buf_t
包含 100 个 char
?
在真实世界示例中这样的选择是有意义的,这将很有帮助,因为我在阅读文档时无法理解它。
最佳答案
每当您执行格式化 I/O 时,您所做的就是连接一堆小字符串。
当你写这样的东西时,想想幕后发生了什么
fprintf(stdout, "Hello, %s!\n", getenv("USER"));
这可以实现(忽略 getenv
的多重计算):
struct iovec bufs[3] = {{"Hello, ", 7}, {getenv("USER"), strlen(getenv("USER"))}, {"!\n", 2}};
writev(STDOUT_FILENO, bufs, 3);
(在实践中,FILE
操作稍微复杂一些——也许没有必要——但大多数情况都这么简单)。
允许直接指定多个缓冲区意味着您不必浪费处理时间(或源代码的复杂性)在写入之前分配单个缓冲区来保存它们。
此外,您是否曾经在 make -j
下运行编译器,以至于它的输出变得非常困惑?这通常是因为它们不这样做 - 相反它们发出几个单独的 write
并且它们与并行进程的写入混合在一起,而不是在单个过程中发出每一行系统调用。
关于c - libuv 和 uv_try_write : why multiple buffers?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38077911/