LINUX.ORG.RU
ФорумTalks

Драма tokio vs async-std

 


0

3

Что-то странное происходит. В одном из устаревших проектов для асинхронного ИО в rust romio появился pull request, который добавил в ридми проекта упоминание tokio как более современной альтернативы поддерживающей новый синтаксис async/await (до этого там было лишь упоминание async-std). Спустя некоторое время, автор pull request’а, и все, кто поставил ему палец вверх оказались в бане. Спустя некоторое время реквест таки замержили, и автор репозитория написал пространный коммент, которые среди прочего упоминает о конфликте между разработчиками tokio и async-std.

Pull request https://github.com/withoutboats/romio/pull/106 Коммент - https://github.com/withoutboats/romio/pull/106#issuecomment-548947560

Кто-то в курсе, в чем вообще суть конфликта между tokio и async-std? Очень любопытно об этом узнать. визаутбоатс пишет, что конфликт непубличный, но в эпоху интернета хотя бы часть инфы должна была просочиться. А я тут в танке сидел за новостями не следил.

PS: «My code is written for people of better character than you, go away.» - фонд золотых цитат прямо)

★★★★★

Какие-то инфантильные они в этих ваших америках.

RazrFalcon ★★★★★ ()

А, так патч прислал русский. Ну тут всё понятно. На них diversity не распространяется.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Да в принципе патч не важен, он был только поводом того, что информация о наличии конфликта между разрабами tokio и async-std была фактически официально объявлена. И хочется деталей чисто технических. Надо ведь знать, на чем писать софт с async/await.

provaton ★★★★★ ()

First of all, the users who find themselves unable to interact with this repo find themselves such because the repo is mine and I have personally blocked them from interacting with me further on GitHub. I cannot speak to any situation involving async-std, because I am not a contributor to that project.

I blocked these users because I do not believe they were acting in good faith in making and supporting this PR. It seems obvious that when a minor readme change to a deprecated project receives dozens of thumbs up within hours that something unusual is going on. In the larger context of known tensions betweens async-std (which shares contributors with this project) and tokio, and in my personal context of having found @kpp to be an aggressive and unpleasant person to engage with, what has happened here is obvious to me. That @kpp has gone on to use this PR on reddit to claim async-std’s maintainers are not «kind and open» is the most disingenuous horseshit imaginable, one wonders if that was his initial hope for this PR, or just a happy outcome for him.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

То есть «он сюда полез, чтобы я его забанил и он смог жаловаться»?

question4 ★★★★★ ()
Ответ на: комментарий от provaton

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Как это альтернатив нет? собственно tokio/async-std и есть пара альтернатив, которые во многом выполняют одну задачу.

provaton ★★★★★ ()

пулреквест замёржен, мудаки пробанены

Всё правильно сделали же.

Pacmu3ka ()

Там у какого-то завистливого петушка горит, ясен же пень, нет никакого конфликта.

WitcherGeralt ★★ ()

А почему async-std не в стандартной библиотеке вообще? Раз Rust такой весь асинхронный, то и функции должны как минимум иметь асинхронную альтернативу.

Legioner ★★★★★ ()

UPD: It appears that ALL commenters have been banned from both this repo and async-std.

А вот и причина против async-std. Его мейнтейнеры — истерички.

hateyoufeel ★★★★★ ()
Ответ на: комментарий от provaton

Сложный вопрос. Как я понял, некоторые особо рьяные личности пытались выпилить все unsafe, что приводило к просадке производительность. Автор либы их вежливо посылал. А они начинали кидаться какашками, мол ты CoC и вообще. В итоге он выложил 1.0 и сказал что забивает на либу, ибо достали. Но вроде по-прежнему пилит потихоньку.

RazrFalcon ★★★★★ ()

https://www.reddit.com/r/rust/comments/dpjlkt/comment/f5yaqz9

Вот тут чувак описывает что futures-rs могут быть основанием для всего асинхронного, но тут-же говорит, что оно так не реализованно в реальности. Короче я нифига не понял:

The odd difference to python is that an effort to build shared interfaces in Rust does exist and it is old: futures-rs. It comes with a ton of traits that help you effectively write software without relying on the type of stream that hands you the data. Maybe, at some point, someone will figure out to also unify those types effectively, but my point is that we’re really not as bad off.

Also, this is a similar problem to ORMs and their support with databases: as a library, you want to be rather generic over all, while in any concrete application, you will make a choice which will last for a while. The futures crate is the way to ensure a common ground.

So, weirdly, we have foundations early where others have none and no common ground at places where you’d imagine people would have just ported community practices over

Вся нить обсуждения: https://www.reddit.com/r/rust/comments/dpjlkt/comment/f5vy4tg

spoonbob ()
Ответ на: комментарий от provaton

Надо ведь знать, на чем писать софт с async/await.

На ЖС А что, кто-то мешает и дальше пользоваться той же самой библиотекой, что и до этого?

Может, я чего не понимаю, в Расте ни бум-бум.

Nervous ★★★ ()

Походу та же бадяга, что и с node.js. Нормального async для ФС неть ни для одной ОС. Токио делает какую-ту хитрую конструкцию на тредпулах, которая несовместима с реализацией async-std

Токио неторопливо мигрирует со старой версии futures-rs на новую. async-std уже

Токио и async-std оба пытаются следовать API стандартной библиотеки, но нескольно по разному

В это время, на crates.io полно библиотек, зависящих от разных 0.0.x версий и альфа-версий токио. А async-std, несмотря на свою юность, хайпует и вот-вот выпустит версию 1.0 чтоб дать всем какие-то гарантии по API

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 5)

https://github.com/withoutboats/romio/pull/106#issuecomment-550413977

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

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

Vit ★★★★★ ()

странно, я думал в любой непонятной ситуации нужно делать форк

chenbr0 ()

Скандалы, интриги, расследования.(цы)

WatchCat ★★★★★ ()
Ответ на: комментарий от spoonbob

Нормального async для ФС неть ни для одной ОС.

Вроде в линуксе сделали какой-то io_uring недавно. В винде всегда был, хз, насколько нормальный.

Legioner ★★★★★ ()
Ответ на: комментарий от spoonbob

Нормального async для ФС неть ни для одной ОС.

Потому что в 99% случаев и нахер не надо, например. Гошечка точно так же юзает треды для файловых операций. Только гошники мужики простые и не ноют, и всё у них работет. В 90% случаев тебе вообще никакой асинронный ввод-вывод нахер не нужен. Разнылись тут.

Pacmu3ka ()
Ответ на: комментарий от Pacmu3ka

Потому что в 99% случаев и нахер не надо, например

А как тогда делать сервер, отдающий статику?

spoonbob ()
Ответ на: комментарий от Legioner

винде всегда был, хз, насколько нормальный

Где-то давно читал нытье автора libuv. Писал что нигде нормального нет

spoonbob ()
Ответ на: комментарий от spoonbob

Как всю жизнь делали, ёпта. Как, по-твоему, nginx под линуксом работает?

Pacmu3ka ()
Ответ на: комментарий от Pacmu3ka

Через некий os-специфичный костыль, о котором я подумал?)

spoonbob ()
Ответ на: комментарий от Pacmu3ka

Смысл в этом есть. Современные SSD нормально разгоняются ближе к 32 потокам. Т.е. твоя программа должна пускать 32 потока, чтобы выжимать максимум из оборудования. Если при этом у тебя асинхронная программа, которая работает в одном потоке, то выглядит это всё глупо. Конечно 32 потока много ресурсов не сожрут, но зачем это всё, если по факту оборудование асинхронное, процессор работает асинхронно. Т.е. получается, что ОС поверх асинхронного оборудования имитирует синхронное АПИ, а твоя программа поверх синхронного АПИ имитирует асинхронное АПИ, лол. В общем ни к чему это.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Да хоть 1024 потока, в чём твоя проблема?

Асинхронный ввод вывод жизненно необходимо для сетевых соединений, коих могут быть сотни тысяч, и запускать 100000 тредов становится дорого. А диск всего один. Или два. У тебя не будет столько дисков, чтобы это стало проблемой. Поэтому асинхронный ввод-ввывод для сокетов реализовали ещё до твоего рождения, а асинхронный ввод-ввывод для дисков никому особо нахер не нужен. В линуксе io_submit добавили сто лет назад - и до сих пор не допилили до юзабельного состояния, потому что никому оно нахер не интересно. Даже nginx его зачем-то поддерживает - и оно выключено по дефолту, потому что нахер не нужно, когда обычный тредпул работает лучше. И даже если включить, всё равно надо использовать тредпул, потому что операции типа fopen() или fstat() всё равно остаются блокирующеми. Сейчас сделали io_uring, но неблокирующих аналогов fopen() или fstat() и там нет и не будет, потому что тупо выделки не стоит при нынешних дисках.

Pacmu3ka ()
Ответ на: комментарий от WitcherGeralt

Tokio старее, работает вполне.

async std начали пилить заново, может сделали что-то лучше. Но само имя как по мне запутывает людей и они думают что это связано с Rust Async Workgroup. По сути получили хайп нагару, но проект сторонний и в нем куча ещё за флагом unstable

Я не против обеих, будем смотреть как проекты выживут.

Конечно в идеале чтобы сам Rust на чем-то стандартизировался, на том или ином

vertexua ★★★☆☆ ()
Ответ на: комментарий от Legioner

Это сторонний проект, который так себя назвал чтобы все думали что это кусок стандартной либы. (В Rust часто библиотеки вроде генерации случайных чисел от core команды кладут в crate)

vertexua ★★★☆☆ ()
Ответ на: комментарий от Pacmu3ka

NVME выдает 500k iops. Один. Удачи утилизировать без асинхронного IO в том или ином виде.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

И сколько из этих IOPS он умеет выполнять параллельно?

Pacmu3ka ()
Ответ на: комментарий от Pacmu3ka

Достаточно, чтобы синхронное выполнение write() в один поток не могло его утилизировать. Даже саташные ssd в один поток не утилизировать, лол. Поэтому начинается огород с тредпулами и прочей глупостью, когда напрашивается обычная асинхронка, которую в итоге сперва сделали коряво (linux aio), а теперь кошерно (io uring).

kirk_johnson ★☆ ()
Ответ на: комментарий от Pacmu3ka

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

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

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

Pacmu3ka ()
Ответ на: комментарий от Pacmu3ka

Ты понимаешь, что такое глубина очереди и почему это важный параметр?

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

Тож CrystalDiskMark юзаеш? ;-)

Когда понадобится больше 1000 параллельных операций, чтобы насытить твой диск, тогда и придёшь сюда ныть про асинхронный ввод-вывод.

Pacmu3ka ()
Ответ на: комментарий от Pacmu3ka

Тож CrystalDiskMark юзаеш? ;-)

Нет, fio.

Когда понадобится больше 1000 параллельных операций, чтобы насытить твой диск, тогда и придёшь сюда ныть про асинхронный ввод-вывод.

Ты понимаешь, что write() в один поток не справляется даже на SATA? Хотя речь о глубине очереди в 32/64 запроса-то всего?

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от Pacmu3ka

Гошечка точно так же юзает треды для файловых операций

Горутины — это не треды.

WitcherGeralt ★★ ()
Ответ на: комментарий от Pacmu3ka

Ну так запусти больше потоков, ёпт.

Приходится либо так, либо с помощью Linux AIO. А теперь делаем еще один шаг и понимаем, что те механизмы, которые мы используем для отправки данных в сеть, можно использовать и для отправки данных в диск. И приходим к тому же linux aio, только с более годной архитектурой. И теперь используя один epoll() можно менеджить весь I/O. Бомбит-то от чего?

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от Pacmu3ka

Ты хочешь сказать, что на работе с файлом горутина блокируется и занимает поток?

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

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

Никак не пойму, тебе IO или поныть? Потому что с IO проблем нет.

Pacmu3ka ()
Ответ на: комментарий от Pacmu3ka

То есть кроме ДЕДЫ ЗАВЕЩАЛИ У МЕНЯ ВСЕ РАБОТАЕТ РЯЯЯЯ мы от тебя ничего не дождемся, верно?

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)