Я её читал, да.

Вывод "проще не юзать блокирующие примитивы синхронизации в асинке" для себя не делал из этого.

То, что в tokio::sync::RwLock допилили fairness, не был в курсе. Круто, спасибо.

Лол зачем юзать блокирующие в асинке?

Чтобы постоянно думать о возможностях блокировки?

Не вытягивай гварды в публичное АПИ и не прийдётся думать.

Лол я в актиксе лочился

Причем пока ab не прогнал дедлоки не ловил

Ну и зачем эти приколы нужны?

Блокирующие синхронизаторы для синхронного кода

Асинхронные для асинхронного

Future::poll - это вполне себе синхронный код.

Это деталь реализации

Не, по-моему это ерунда какая-то. Ребят, мне нравится идея futures-signals. Изучение этой библиотеки навело меня на мысль, как мне лучше организовать мой собственной код, так что ваш совет мне безусловно помог. Но саму библиотеку я бы юзать для своих целей пока не стал. Мне кажется, что автор делал этот фреймворк с прицелом на то, что Mutable будет сидеть в синхронном main-thread, в котором, грубо говоря, winit хендлер крутится, и просто сохранять туда события в каком-то виде, а сигналы будут раздаваться уже в Futures среду, в какой-нибудь Tokio экзекьютор. В этом смысле подход вполне разумный, но это API совершенно не общего назначения, как позиционируется в библиотеке: потенциально блокирующие poll сигналов — не есть гут; Mutable, потенциально блокирующие фьючеры — тоже не есть гут. Ну и, кроме того, сам интерфейс Signal из-под капота использует врапперы над обычными стримами из Futures. По сути в сухом остатке мы просто имеем интерфейсную обертку над стримами из Фьючеров, и std RwLock.

Я просто ожидал, что оно там как-то более умно сделано изнутри, а там по сути под капотом просто обычный враппер, причем над не очень совместимыми вещами

я думал ты эту либу и воспримешь как информацию к размышлению

Но концепция безусловно хорошая.

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

Думаю, более правильно такое можно было бы сделать используя токиовский RwLock действительно, а в сигнал передавая значения через watch канал. Сигнал ведь по сути не хранит состояние

угу, и как стендовое решение можно взять код и подправить его)

хотя я понимаю, что нет ничего более постоянного, чем временное 😉

А есть какой-то красивый способ получить последний элемент из стрима?

Что-нибудь лучше чем
let mut last = None;
while let next @ Some(_) = lines.next().await { last = next }