Уход от копирайта в действии

А кто-нибудь помнит Punch quest?

#prog #rust

Faster compilation with the parallel front-end in nightly

TL;DR:

RUSTFLAGS="-Z threads=8" cargo +nightly build --release

Пока что на nightly, потому что в реализации всё ещё есть баги, вызывающие дедлоки, и потому что параллельность фронтенда пока что не эксплуатируется в полной мере.

Использование threads=1 в среднем примерно на полтора процента медленнее текущего однопоточного фронтенда.

Как ни странно, бекенд это тоже в некоторой степени ускоряет, потому что генерация LLVM IR для codegen unit-ов также происходит параллельно.

- а как ты дебажишь Rust в проде?
- я заливаю специальную сборку
- что за сборка? ты же не просто обложил её принтами?
- ...

#prog #rust

В Google переписывают Android binder (компонент ядра для IPC) с C на Rust. Это компонент, который используется практически всем на Android, а потому для нормального функционирования он должен быть быстрым и корректным.

Авторы ожидают, что переписывание кода позволит и дальше развивать binder, избавиться от накопившегося техдолга и повысить его безопасность.

В качестве преимуществ Rust называют:

* возможность закодировать в системах типов инварианты, которые в C надо поддерживать самостоятельно.
* деструкторы, избавляющие от необходимости вручную освобождать ресурсы (корректная деинициализация в C требует неловкого паттерна goto cleanup).
* обработка ошибок проще: игнорирование потенциальных ошибок приводит к ошибке компиляции.

Переписанный вариант имеет отличную от текущего варианта Binder архитектуру, но имеет почти ту же функциональность. Пока что не реализованы фичи для отладки. Все тесты проходят, а бенчмарки показывают, что переписанный вариант сопоставим по производительности с исходным (где-то быстрее, где медленнее). Автор патча при этом отмечает, что это синтетические бенчмарки и для полной уверенности следует проверить производительность на реальной системе.

В наборе патчей непереписанным остался компонент binderfs:

We have left the binderfs filesystem component in C. Rewriting it in Rust would be a large amount of work and requires a lot of bindings to the file system interfaces. Binderfs has not historically had the same challenges with security and complexity, so rewriting binderfs seems to have lower value than the rest of Binder.

Не нравятся недалёкие?

Отойдите.

Пере-переслал, не хочу давать публичности каналу-источнику

#prog #rust хайлайты:

▪️Несколько изменений, связанных с гарантиями языка:
🔸char имеет одинаковый с u32 размер и выравнивание
🔸null-указатель имеет нулевой адрес. Насколько я понимаю, у разработчиков Rust нет планов поддерживать платформы, где это не так.
🔸касты между разнымии типами сырых указателей на слайсы (и содержащими их DST) сохраняют число элементов в части метаданных жирных указателей
🔸для некоторых типов гарантируется, что transmute от нулевых байт в Option от этого типа легален и даёт None.

▪️Следующие операции теперь доступны к const-контексте:
🔸std::mem::discriminant
🔸BinaryHeap::{new, new_in}
🔸Операции для байтовых смещений указателей (и в принципе стабилизированы)
🔸std::mem::zeroed и MaybeUninit::zeroed

▪️Парсер теперь избегает патологического квадратичного поведения на больших последовательностях непарных угловых скобок (до фикса подобный код приводил к OOM).

▪️Реализации Ord, PartialOrd и Hash для SocketAddr{V4, V6} теперь дерайвятся, а не написаны вручную. До этого изменения реализация PartialEq для SocketAddrV6, как и всякий дерайв, сравнивала все поля, включая flowinfo и scope_id, а вот реализации трейтов для упорядочивания эти поля игнорировали. По какому-то недоразумению этот баг просуществовал 28 версий!

▪️Компилятор теперь замечает, когда на значении вызывается метод трейта, реализованный для его типа, и предлагает импортировать трейт вместо того, чтобы предложить его реализовать.

▪️Компилятор теперь корректно отлавливает ситуации, когда тип становится слишком большим из-за паддинга

▪️При panic_immediate_abort теперь меньше втягивается связанного с паникой кода.

▪️При невозможности создания трейт-объекта из трейта компилятор теперь предлагает использовать enum, если число типов, реализовывающих трейт, невелико (и предлагает использовать тип напрямую, если всего один тип реализует трейт).

▪️Компилятор при попытке сделать биндинг на unsized значение теперь жалуется только на let вместо всех мест, где используется этот биндинг.

▪️Компилятор на попытку сконструировать кортежную структуру с приватными полями теперь предлагает вызвать конструктор (при его наличии). Фиксит issue от 2015 года!

К сожалению, сейчас сделано довольно костыльно, но нормальный фикс затруднителен.

▪️Компилятор теперь диагностирует некоторые случаи, когда у лямбды забыты аргументные скобки или они выставлены неверно.

▪️Стабилизирован инлайн-ассемблер с бекендом cranelift.

▪️Компилятор восстанавливается на коде вида S { ref field: name } и предлагает переписать на правильный S { field: ref name }.

▪️Стабилизированы API для манипуляции с временными отметками файлов.

▪️offset_of! теперь поддерживает поля внутри вариантов enum.

слишком сложно.

#prog #article

LSP could have been better — Кладов рассказывает о технических аспектах LSP (как понятно из заголовка, не всегда хороших)

#prog #amazingopensource

ast-grep — инструмент для структурного поиска и замены с паттернами не на уровне текста, а на уровне синтаксических деревьев.

Построен поверх tree-sitter, поэтому охват языков, корректность и произодительность на уровне.

Поддерживает интерактивный режим, который позволяет проверить все места, где применяется правило, перед совершением реальной замены.

Поддерживает предзаписанные правила (в YAML 😒), с возможностью вынесения в отдельные файлы общих определений.

Может быть использован как линтер, для поиска паттернов, но без замены.

#meme

Жиза

#prog #rust #rustasync

Хозяйке на заметку

(или "Антон читает за вас документацию tokio")

1. Если вам требуется заспавнить несколько тасок с одинаковыми типами возврата, в количестве, известном только в рантайме, и дождаться результата исполнения каждой из них или только некоторых, то в tokio есть для этого готовый примитив: JoinSet.

Базовый пример использования:

use tokio::task::JoinSet;

#[tokio::main]
async fn main() {
    let mut set = JoinSet::new();

    for i in 0..10 {
        // таски спавнятся при помощи spawn, поэтому
        // семантика та же: сразу начинают выполняться
        // и паникует вне асинхронного контекста tokio
        set.spawn(async move { i });
    }

    let mut seen = [false; 10];
    // мы не обязаны получать все таски до конца
    while let Some(res) = set.join_next().await {
        let idx = res.unwrap();
        seen[idx] = true;
    }

    for i in 0..10 {
        assert!(seen[i]);
    }
}

Также можно отменить скопом все таски в наборе через abort_all. Также можно переиспользовать JoinSet, используя detach_all. Это уберёт все таски из JoinSet, но они продолжат исполняться рантаймом.

2. Если у нас есть несколько тасок, которые отсылают результаты своей работы через канал, и мы хотим ограничить число одновременно исполняемых тасок, то это можно сделать при помощи канала ограниченной ёмкости и API, описанного в статье Mutex without lock, Queue without push: cancel safety in lilos (о которой я уже рассказывал):

let (tx, mut rx) = tokio::sync::mpsc::channel(limit);

for _ in 0..n_tasks {
    let work = async {
        // какая-то полезная работа
    };
    let tx = tx.clone();
    let task = async move {
        let send_permit = tx.reserve_owned().unwrap();
        let result = work.await;
        let _ = send_permit.send(result);
    };
    tokio::spawn(task);
}

// дропаем свою копию Sender-а, чтобы не заблокироваться
// на чтении из канала, в который никто не пишет
drop(tx);
while let Some(res) = rx.recv().await {
    // обрабатываем результат
}

И надо предупредить (хотя навряд ли вы в такое вляпаетесь намеренно): очевидно, если Permit-ов утечёт достаточно много, вы можете оказаться в дурацкой ситуации, когда в канале есть место, но он не работает ни за отправку, ни на получение.