libuv и uv_buf_init: кто что должен освобождать?

Рассмотрим официальную документацию для libuv (раздел разные утилиты).
Это объявление uv_buf_init:

uv_buf_t uv_buf_init(char* base, unsigned int len)

В документации говорится, что (выделено мной):

Конструктор для uv_buf_t.

Из-за различий в платформах пользователь не может полагаться на порядок элементов base и len структуры uv_buf_t. Пользователь несет ответственность за освобождение базы после выполнения uv_buf_t. Возвращает структуру, переданную по значению.

Мне кажется, что base можно освободить сразу после обращения к uv_buf_init.

С другой стороны, структура uv_buf_t задокументирована как состоит из двух полей: base с типом char * и len с типом size_t.

Что мне непонятно:

  • Копируются ли данные в буфер? (Ну, я полагаю, что ответ отрицательный, потому что это было бы большим штрафом с точки зрения производительности).

  • Должен ли я освобождать данные после вызова uv_try_write или других функций *_write? То есть после того, как данные действительно были использованы.


c libuv
person skypjack    schedule 28.06.2016    source источник
comment
Вы должны использовать valgrind для проверки или также прочитать исходный код, если документации недостаточно. Кроме того, различия платформ в том, где он фактически хранится, кажутся мне несущественными.   -  person Ryan    schedule 28.06.2016
comment
@self Прочитайте источник и да: документации недостаточно (это действительно ужасно).   -  person skypjack    schedule 29.06.2016

Ответы (2)


arrow_upward
0
arrow_downward

Не беспокойтесь о struct, но беспокойтесь о том, на что он указывает.

Если функция, которой вы передаете uv_buf_t, используется асинхронно, память, на которую указывает uv_buf_t.base, не должна не освобождаться до тех пор, пока не будет вызван обратный вызов.

Даже отмена выполняемых запросов, таких как uv_write_t (вызовом close для дескриптора), не предотвращает вызовы обратных вызовов, поэтому безопасно выполнять очистку там.

person Hans Malherbe    schedule 27.10.2016

arrow_upward
0
arrow_downward

Данные не копируются в uv_buf_t, uv_buf_t.base ссылается на тот же массив символов, который вы использовали для его создания.
Из-за этого у вас нет штрафов за производительность, но вы также не можете удалить данные сразу после вызова uv_buf_init.
Вместо этого вы можете освободить их, как только вы использовали буфер, то есть (в качестве примера) когда вы отправили его uv_write или uv_try_write.

person skypjack    schedule 29.06.2016