Ну хорошо, я загрузил текстовых документ, правлю область 10 строк, в думах как Сократ, остальная память не используется до конца программы

Вывод: остальное утекло?

В твоём случае остальная память может использоваться в зависимости от действий юзера.
Я тебе привёл пример, когда остальная память не может использоваться никогда, никаких входных данных нет, а задетектить ты это всё равно не можешь.

Но да, в бытовом смысле если текстовый редактор не выгружает из памяти неиспользуемые области файла, то он течёт.

Дак в этом и проблема

Определение зависит от наблюдателя

let smth = allocate();
thread::spawn(|| {
    maybe_halts();
    now_use(smth);
});

Не зависит.
Вот этот пример — функция maybe_halts(); не имеет входных параметров. Она статически, на этапе компиляции, либо завершается, либо нет.

Но определить ты это не можешь.

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

В обоих случаях утечки нет

Лишние инструкции есть, ну и ладно

Есть — у тебя программа в основном треде продолжает делать какую-то работу. Побочный тред у тебя либо циклится навечно (и тогда smth нужно освободить сразу), либо нет (и тогда smth освобождать нельзя). Главный тред делает что угодно другое.

Главный тред не может обратиться к памяти в побочном, потому что мы её туда мувнули (или исходно аллоцировали в побочном).
Побочному треду не потребуется эта память, если он зациклился.

Ну хорошо, предположим, но вывод становится примерно следующим, есть ряд ситуаций неразрешимых с математической точки зрения

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

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

Но в данном примере проблема в том что если нет короткого пути данные должны быть сразу подготовленны к выгрузке

А если доказанно что ждать очень долго, то выгруженны сразу же

Вообщем случае оно может быть сильно срелаксированно

в актиксовых акторах при передаче от одного актора сообщения к другому как можно реализовать следующее одновременно:
1) Отправить актору сообщение, не дожидаясь ответа от него
2) Если очередь на актор переполнена, то отправка должна заблокироваться до тех пор, пока очередь не освободится

1ый вариант реализуется через do_send, но он запихивает сообщение в очередь даже если она полна
2ой вариант реализуется через send, но оно ждёт ответа, а не этого не нужно.

Какие ещё есть варианты помимо вкорячевания своей очереди для общения между акторами вместо актиксовой?