История вопроса: Алгоритм Drop Check (dropck) был введен для закрытия уязвимости типобезопасности в ранних версиях Rust, где обобщенные деструкторы могли обращаться к данным, которые уже были освобождены. До dropck можно было создать структуру, содержащую ссылку на данные, выделенные в стеке, реализовать Drop для разыменования этой ссылки, и иметь возможность освободить данные до контейнера, что ведет к использованию после освобождения памяти. Эта проблема стала критичной с появлением обобщенных коллекций, которые могли содержать заимствованные данные, что потребовало консервативного анализа для обеспечения безопасности деструкторов.
Проблема:
Когда обобщенный тип Container<T> реализует Drop, компилятор должен гарантировать, что T строго существует дольше, чем контейнер, чтобы предотвратить доступ деструкторов к недопустимой памяти. Для типов, использующих сырые указатели (например, *const T), компилятор не имеет информации о сроках жизни, поскольку сырые указатели не отслеживаются проверяющим заимствование. Без явных маркеров времени жизни компилятор не может проверить, лишится ли деструктор возможности разыменовывать указатель на данные, принадлежащие текущей области, которые могут быть освобождены первыми.
Решение:
PhantomData действует как маркер нулевого размера, который моделирует владение или заимствование типа T или времени жизни 'a. Включив PhantomData<&'a T> в структуру, содержащую сырой указатель, вы информируете компилятор о том, что структура логически содержит ссылку, связанную с временем жизни 'a. Алгоритм Drop Check использует это для обеспечения того, чтобы структура не могла существовать дольше 'a. Если структура реализует Drop и потенциально может существовать дольше своего обозначенного, компиляция завершается ошибкой, предотвращая неопределенное поведение.
Вы разрабатываете парсер сетевого протокола с нулевым копированием, который оборачивает байтовый буфер. Вы определяете Packet<'a>, содержащий сырой указатель *const u8 на временный Vec<u8>, полученный от сетевого стека. Вы пытаетесь реализовать Drop для Packet, чтобы обновить статистику парсинга, прочитывая через сырой указатель. Опасность заключается в том, что Vec<u8> освобождается, когда функция получения завершает свою работу, но Packet может храниться в очереди для последующей обработки, что приводит к использованию после освобождения, когда выполняется Drop.
Сначала вы рассматриваете возможность использования ссылки &'a [u8] вместо сырого указателя. Это позволяет использовать проверяющий заимствование для обеспечения того, чтобы буфер жил достаточно долго. Однако это значительно ограничивает API, так как вы не можете свободно перемещать пакет или хранить его в коллекциях, которые требуют ограничений 'static, и это мешает самоссылочным паттернам, распространенным в парсерах.
Во-вторых, вы рассматриваете возможность использования Rc<Vec<u8>> для совместного владения буфером. Это гарантирует, что данные останутся действительными, пока существует хотя бы один пакет. Недостатком является стоимость производительности на счетчик ссылок и выделение памяти в куче, что нарушает требования к нулевому копированию и нулевым накладным расходам для сетевой обработки с высокой пропускной способностью.
В-третьих, вы рассматриваете добавление PhantomData<&'a ()>, чтобы обозначить зависимость времени жизни, сохраняя при этом сырой указатель для производительности. Однако это показывает, что реализация Drop здесь по своей сути небезопасна, потому что компилятор не может гарантировать, что буфер переживет пакет. Вы решаете удалить реализацию Drop и вместо этого использовать метод ручной очистки, который вызывается перед тем, как буфер будет освобожден, или переключиться на Cow<'a, [u8]>, чтобы поддерживать как заимствованные, так и принадлежащие данные.
Вы выбираете подход Cow<'a, [u8]>, который исключает сырой указатель и необходимость в небезопасной логике Drop. Результат — парсер, который успешно компилируется с строгими гарантиями времени жизни, гарантируя, что ни один пакет не может существовать дольше своего основного буфера, при этом поддерживая производительность для заимствованного случая.
Почему компилятор позволяет реализовывать Drop для структуры, содержащей PhantomData<&'static T>, но отклоняет это для PhantomData<&'a T>, где 'a является не статическим?
Когда время жизни 'static, ссылки на данные живут на протяжении всей работы программы, поэтому нет возможности освобождения памяти до запуска деструктора. Когда 'a — это локальное время жизни, данные могут быть освобождены, пока структура все еще существует, создавая доступ к висячей ссылке в Drop. Компилятор отклоняет случай локального времени жизни, потому что не может доказать, что деструктор не обратится к данным после их освобождения, в то время как 'static предоставляет эту гарантию по своей сути.
Как PhantomData<T> (семантика владения) отличается от PhantomData<&'a T> (семантика заимствования) в контексте dropck, и почему первая не предотвращает выход структуры за пределы своей области?
PhantomData<T> указывает на то, что структура ведет себя так, как будто она владеет T, что влияет на вариативность и проверку на освобождение, предполагая, что структура может освободить T, но не связывает время жизни структуры с конкретным заимствованным временем жизни 'a. Поэтому компилятор подразумевает, что структура может существовать дольше, чем любые локальные данные, если только T сам не содержит сроков жизни. В отличие от этого, PhantomData<&'a T> явно ограничивает структуру временем жизни 'a, что гарантирует, что она не может существовать дольше, чем заимствование, и таким образом предотвращает использование после освобождения памяти в деструкторах.
Какова была цель атрибута may_dangle (нестабильного/устаревшего) в отношении dropck, и как он применялся к таким типам, как Vec<T>?
Атрибут #[may_dangle] позволял небезопасному коду информировать компилятор о том, что реализация Drop для типа не будет обращаться к содержимому обобщенного параметра T, даже если T не живет строго дольше контейнера. Это было критически важно для коллекций, таких как Vec<T>, которые владеют своим буфером, но не нуждаются в чтении значений T в процессе освобождения (они просто освобождают память). Кандидаты часто упускают, что Drop Check по умолчанию является консервативным, предполагая, что Drop может обращаться ко всему, и что may_dangle был механизмом, позволяющим отказаться от этого предположения для гибкости в коллекциях, хотя это требовало небезопасного кода и строгих инвариантов, чтобы предотвратить доступ к висячим данным.