https://kotlinlang.org logo
Join Slack
Powered by
Есть "корутины для чайноков"? Я никак въехать не м...
# russian
l
Есть "корутины для чайноков"? Я никак въехать не могу. Корутины, контексты, билдеры, каналы, акторы...
a
Просто не надо делать корутины ради корутин. Идите от задачи.
l
Ну... инструменты хорошо бы знать наперед, хоть немного. Но задача действительно есть: кроссплатформенный код для эмуляции реакции автоматических выключателей на параметры тока. Физика упрощена для этой эмуляции, но вот эти выключатели должны реагировать многопоточно, независимо. Кроссплатформенность нужны потому что логика одинаковая и на бекенде, и на сайте и на десктопном приложении.
a
Напишите конкретнее. И если физика, то добро пожаловать в #science
Как параметры тока считываются?
l
Я тогда в личку чтоли.. напишу Нет, это не физика
a
зачем?
Публичное обсуждение - это полезно
l
А... ну ок
a
Я к тому, что есть попытка внедрить kotlin в научное комьюнити, так что если есть хоть какое-то научное или инженерное применение - надо рекламировать.
l
Рекламировать что?
a
применение котлин в этих сферах
l
Так... сначала задача. Потом про это поговрим)
Ну, есть электрическая сеть (та что по столбам на улице). На этих столбах есть умные выключатели. Они размыкаются, если "слышат" КЗ и замыкаются если с однйо стороны пропало электричество, а другой оно осталось. Так же ими можно удаленно управлять. Все это упрощается и уже рассчитывается и требуется написать логику этих выключателей. Я могу как либо сообщать выключателям, что ситуация с электричеством поменялась (или просто сообщать текущее состояние сети), что они слышат кз или что им послали команду.
При этом, у выключателей есть задержка при работе, которую хорошо бы эмулировать. Они слышат КЗ и выключаются не сразу, а за сколько то мс. Они включаются при пропадании электричества не сразу, а с приличной задержкой.
Мало того, когда они услышали кз - они выключатся, потом через сколько то мс включатся, чтобы "дожечь" предмет кз. И так будут щелкать несколько раз.
При этом... вот один выключатель услышал КЗ - выключился. А его сосед засек что напряжения нет и включился, попал на то же КЗ, выключился. Эти события взаимосвязаны.
a
Хорошо, примерно понятно. Как идут данные, непрерывным потоком (измерения в фиксированное время) или событиями?
l
Я думаю, тут корректно рассматривать и измерения в фиксированное время и события.
Для состояния сети данные (где есть напряжение и где кз) будут прилетать сразу всем эмуляторам при изменении сети. Так проще я думаю, чтобы не помнить что там кому послал и надо ли ему апдейт слать. Просто сообщаем текущее состояние сети, которое может не отличаться от предыдущего для этого выключателя.
Состояние сети для выключателя - это наличие напряжения на его концах и наличие кз. Это уже упрощено.
t
Джва года жду гайд "rx->coroutines migration"
l
А корутины больше на rx (который я тоже не знаю) похожи или на потоки?
a
То есть общий event bus. Это похоже на задачку для BroadcaseChannel. У вас в него с одного конца пихаются события, потом у вас кто-то подписывается на события этого канала (смотрите документацию и задачайте вопросы). Дальше, мы делаем на подписчике 
consumeEach
и просто обрабатываем все события. Если в событии случилось что-то интересное, то реагируете (подразумевается что в событии есть обратный адрес).
l
Как мне кажется - надо сделать актор. В канал которому и слать сообщения.
a
Актор может быть подписчиком на канал
По сути да, это классическая акторная модель.
c
Отвечая на первоначальный вопрос. Очень неплохая вводная от Романа Елизарова:

https://www.youtube.com/watch?v=rB5Q3y73FTo▾

l
А... этот.. эмулятор как омжет реагировать. У него два выхода. В один он может послать какие то данные (логи, json какой нить). А в другой - сообщить замкнулся он или разомкнулся.
a
Ну у вас же все реактивное. Идет цепочка событий, вы в ракцию на события можете кидать логи или кидать сообщение о замыкании
просто делаете внутри своего обработчика (к примеру, актора), 
withContext(<myLogContext>){doLogging}
l
Дело в том, что я не понимаю что за withContext и прочее
a
смена контекста в общем случае нужна чтобы не делать всякие бяки типа io логирование в контексте обработки
Ну тут действительно можно почитать/послушать Елизарова. Вы пока напишите как пишется, потом если код будет, можно посмотреть, где надо подправить.
l
Я пошел, послушаю елизарова по ссылке выше
a
Я еще рекомендую нарисовать схемку потока данных, по ней все будет сразу понятнее
l
Я представляю как это все происходит. Я корутины не представляю, не понимаю
g
Джва года жду гайд "rx->coroutines migration"
Рано. Пока cold streams не появятся. Я тоже жду :( : https://github.com/Kotlin/kotlinx.coroutines/issues/945
ну, человек же rx java заменять собрался. А rx это операторы. JB сказали операторов не будет, пока cold streams не будет. Значит и замены rx до тех пор не будет.
l
Я не собирался rx заменять. У меня его нет и я его не знаю
g
речь не о тебе
a
делайте отдельную ветку для rx
а то как в телеграме
g
я цитировал @thevery выше. Но да, лучше отдельно.
l
@Czar Спасибо, про корутины стало понятнее. Забавно, именно этот ролик я не видел. Помогло.
👍 1
Жаль, он каналы и акторы не зацепил
c
Зацепил чуть чуть, когда про CSP говорил, но ролик немножко старый, а корутины очень активно разрабатываются. Есть и поновее инфа, но на русском не смотрел.
r
Ну и да, мультиплатформенной многопоточности на корутинах пока нету.
l
Ну на common я могу написать это многопоточно? Чтобы в jvm оно работало многопоточно а в js - ну как будет.
a
Корутины не для многопоточности вообще говоря сделаны, но да, их удобно использовать и для этого.
Ну на common я могу написать это многопоточно? Чтобы в jvm оно работало многопоточно а в js - ну как будет.
да
это будет определяться диспатчером.
t
У @elizarov есть несколько хороших статей на medium про контексты и т.п. https://medium.com/@elizarov/coroutine-context-and-scope-c8b255d59055 https://medium.com/@elizarov/structured-concurrency-722d765aa952
22 Views
Open in Slack
PreviousNext
Powered by