libuv 和 uv_buf_init:谁应该释放什么?
libuv and uv_buf_init: who should free what?
考虑 libuv 的官方 documentation(第 杂项实用程序)。
这是 uv_buf_init
:
的声明
uv_buf_t uv_buf_init(char* base, unsigned int len)
文档指出(强调我的):
Constructor for uv_buf_t.
Due to platform differences the user cannot rely on the ordering of the base and len members of the uv_buf_t struct. The user is responsible for freeing base after the uv_buf_t is done. Return struct passed by value.
在我看来,base
可以在调用 uv_buf_init
后立即释放。
另一方面,uv_buf_t
结构 is documented 由两个字段组成:base
,类型为 char *
,和 len
,类型为 size_t
.
我不清楚的是:
是否将数据复制到缓冲区中? (嗯,我想答案是否定的,因为这在性能方面会是一个很大的损失)。
我是否应该在调用 uv_try_write
或其他 *_write
函数后释放数据?也就是说,一旦数据确实被消费了。
数据不会复制到 uv_buf_t
,uv_buf_t.base
指的是您用来创建它的相同字符数组。
因此,您没有性能损失,但也不能在调用 uv_buf_init
.
后立即删除数据
相反,您可以在 使用 缓冲区后释放它们,也就是说(作为示例)当您将其提交给 uv_write
或 uv_try_write
.
不用担心 struct
,但要担心它指向什么。
如果您将 uv_buf_t
传递给的函数以异步方式使用,则 uv_buf_t.base
指向的内存必须 不会 被释放,直到回调被调用。
即使像 uv_write_t
这样取消正在进行的请求(通过在句柄上调用 close)也不会阻止调用回调,因此在那里进行清理是安全的。
考虑 libuv 的官方 documentation(第 杂项实用程序)。
这是 uv_buf_init
:
uv_buf_t uv_buf_init(char* base, unsigned int len)
文档指出(强调我的):
Constructor for uv_buf_t.
Due to platform differences the user cannot rely on the ordering of the base and len members of the uv_buf_t struct. The user is responsible for freeing base after the uv_buf_t is done. Return struct passed by value.
在我看来,base
可以在调用 uv_buf_init
后立即释放。
另一方面,uv_buf_t
结构 is documented 由两个字段组成:base
,类型为 char *
,和 len
,类型为 size_t
.
我不清楚的是:
是否将数据复制到缓冲区中? (嗯,我想答案是否定的,因为这在性能方面会是一个很大的损失)。
我是否应该在调用
uv_try_write
或其他*_write
函数后释放数据?也就是说,一旦数据确实被消费了。
数据不会复制到 uv_buf_t
,uv_buf_t.base
指的是您用来创建它的相同字符数组。
因此,您没有性能损失,但也不能在调用 uv_buf_init
.
后立即删除数据
相反,您可以在 使用 缓冲区后释放它们,也就是说(作为示例)当您将其提交给 uv_write
或 uv_try_write
.
不用担心 struct
,但要担心它指向什么。
如果您将 uv_buf_t
传递给的函数以异步方式使用,则 uv_buf_t.base
指向的内存必须 不会 被释放,直到回调被调用。
即使像 uv_write_t
这样取消正在进行的请求(通过在句柄上调用 close)也不会阻止调用回调,因此在那里进行清理是安全的。