Взгляд на Tokio: как устроен этот асинхронный обработчик событий

[mwizard]

Да это же один в один asyncio из Python 3. Теперь осталось обернуть futures в полноценный псевдосинхронный async/await.

[Gorthauer87]

Ты не поверишь.
https://crates.io/crates/futures-await
Работает, правда, только на nightly.

[Fedcomp]

В nigthly rust есть github.com/alexcrichton/futures-await

[Hixon10]

Ровно, как и «один в один» Netty. Да и, наверное, любой NIO-фреймворк. Все мы пляшем вокруг poll.

[potan]

Лучше бы сделали аналог do в Haskell и for в Scala. Можно было бы писать на полноценных фьючах чистый и понятный код, не засоряя его async/await.

[Googolplex]

async/await существенно удобнее for/do. Только лишь с помощью комбинаторов очень многие паттерны выражать безумно геморройно. Год назад в одном проекте на скале большие асинхронные методы сначала мы пытались писать с помощью комбинаторов и for. Получалось совершенно нечитаемое месиво. После перехода на scala-async код стал чище и понятнее на порядок.

С async-await в Rust писать асинхронный код очень легко и приятно. А с недавними разработками в области immovable generators станет все совсем хорошо.

[Gorthauer87]

Интересно, а если оператор? Перегрузить в качестве комбинатора? Должно сейчас же на найтли сработать вместо await

[potan]

В Haskell это сделано оператором (>>=)
То есть

do
   x <- future1
   y <- genFuture2 x
   pure y

можно записать как

future1 >>= genFuture2

Но практика показывает, что do обычно читабельнее.
В Scala вместо оператора (>>=) почему то сделали метод flatMap. for вызлядит симпатичнее.

for {
  x <- future1
  y <- genFuture2(x)
} yield {
  y
}

против

future1.flatMap(genFuture2)

[mayorovp]

А теперь добавьте в код несколько циклов…

[potan]

Вот в циклах с async/await я бы работать не рискнул, поскольку не очень понимаю его семантику в этом случае. Использовавшие его коллеги в этих случаях сталкивались с неожиданностями.
Я обычно использую sequence, которая меняет местами Seq и монаду (в данном случае Future).

[mayorovp]

А что не так с семантикой?

await приостанавливает выполнение асинхронной функции (освобождая поток) пока не произойдет события. Его семантика никак не меняется в цикле.

[potan]

То есть не гарантируется, что он не будет удерживать нить во время ожидания?

[mayorovp]

Гарантируется.

Ну, на самом деле зависит от реализации, но реализация без таких гарантий будет ошибкой.

[potan]

Тогда я не понимаю в какой код преобразуется

async {
   for( i <- Seq(1,2,3,4)) {
      val x = await { f(i) }
      println(x)
   }
}

[mayorovp]

Ну так скопмпилируйте а потом декомпилируйте обратно...

Если это Scala — то скорее всего там конечный автомат с тремя состояниями будет.

[Googolplex]

В скале это не сработает (т.к. for маппится на метод foreach, а сквозь методы async/await скальный не работает), но сработает, если заменить на цикл while. И да, это преобразуется в конечный автомат, как и в большинстве реализаций async/await (например, в Rust тоже).

[humbug]

То есть не гарантируется, что он не будет удерживать нить во время ожидания?

Для таких гарантий должны соблюдаться несколько правил:

• операции должны быть неблокирующими. poll_read для fs (а иногда и для для stdin) является блокирующим вызовом.
• должны быть зарегистрированы другие фьючи, чтобы дать возможность executor'у переключиться на другую задачу

[potan]

Я работал с кодом на Scala, активно использующим async/await. Как правило, простой способ в нем разоблаться был переписать на for — код сразу получался компактнее и структурированиее.
Явное использование flatMap может выглядеть громозко и страшно, но с for такой проблемы нет.

[fafhrd91]

Да нету там ничего общего, разве что epoll and kqueue

[humbug]

С появлением Tokio стало ясно, что используемая библиотека Mio устарела

mio не может устареть, так как автор tokio по совместительству является автором mio, под капотом tokio — обертка над mio, которая активно обновляется. Уж вы-то должны это знать.

Устарели вы, а не tokio. Мало того, что вы до сих пор сидите на tokio-core, который, вообще-то уже deprecated, у вас какое-то самописное threadpool говнище, которое жрет мои ресурсы, вы создаете кучу тредов, хотя вас об этом не просили, так у вас обработка сокетов вообще однопоточная.

Почитайте ветку, вам многое станет ясно.

[humbug]

Более того, stream легко может быть преобразован в future при помощи адаптера into_future.

Это слегка "заблуждение". Лучше продемонстрировать на примере futures v0.2. В новой версии авторы переименовали комбинатор .into_future() в .next(). Что сразу проясняет ситуацию.

[fafhrd91]

Единственно tokio медленней на 20% чем tokio-core, а так все хорошо

[humbug]

Медленнее в однопоточном режиме. В многопоточной обработке событий мое приложение стало на 5% быстрее. Мы будем улучшать производительность. Закрыто много багов, улучшили архитектуру, вот что главное.

[fafhrd91]

Моё многопоточное приложение стало на 20% медленнее. Если что tokio-core не ограничивает количество потоков. К тому же забавно смотреть как hyper откатывает tokio на старую версию tokio-core чтобы в бенчмарках выглядеть лучше.

[humbug]

Тем забавнее наблюдать за бенчмарками, ведь tokio-core сейчас является фасадом для tokio.

[fafhrd91]

В этом то и прикол что hyper даунгрейдеулся на версию tokio-core="=0.1.12" в которой tokio не используется. Я сделал тоже самое, и в своих проектах сделал также. Каждому своё конечно, но как-то терять 20% не очень

[humbug]

Почему-то все забывают о починенных в tokio багах в погоне за скоростью.

[fafhrd91]

Я что-то не уловил про баги? Какие баги? Я довольно близко знаком с tokio, не могу припомнить никаких, по крайней мере никаких фиксов в комит логе не вижу. если для вас потеря 20% это нормальн для не меня это не приемлемо.

[humbug]

Вот фикс бага. Без него нет возможности возвращать ошибку из UdpCodec::encode, соответственно единственный способ обработать нестандартную ситуацию — упасть. В дальнейшем этот фикс позволил отказаться от разделения кодеков tcp и udp, используя одни и те же типажи: Encoder и Decoder.

Я помню этот фикс, потому что он был сделан мной.

Я довольно близко знаком с tokio

Вы спорите с контрибьютером с вкладом в 3к строк кода и 11 закрытых PR. Но у вас-то наверняка больше)))

[Gorthauer87]

Сам mio то нет, но мы использовали устаревшую версию 0.5 и встала необходимость либо переписывать все под 0.6 либо сразу попробовать мигрировать на более высокоуровневый tokio.

По поводу остального думаю будет конструктивнее, если вы опишете свое видение проблемы в виде Github issue.

[humbug]

По поводу остального думаю будет конструктивнее, если вы опишете свое видение проблемы в виде Github issue.

Может вы еще хотите, чтобы я в вашу репу коммитил? Ваши HR пытались меня к вам заманить, собеседования всякие устраивали, но когда они 2 раза перенесли техническое, это был эпичный провал.

Так что спасибо, но нет))