корунтины решают проблему, потоки -нет

корунтины меньше стоят чем потоки

код с корунтинами, может (подчеркиваю!) выглядеть красивей\читабелней чем с потоками

before/after action — оборачивает все методы контроллера сразу — позволяет ли вообще пропустить выполнение экшена? — позволяет ли подменить результат экшена?

В приведенном выше примере декоратор так же обернет только метод, возвращающий коллекцию других методов. Да, можно таким образом подменить результат экшна (выбрать нужную функцию и декорировать ее), можно отменить выполнение (подменив на пустую функцию), но тут уже серьезной логикой в роутере попахивает :) Вариант без наследования контроллера и именованных методов-экшнов выглядит и правда более гибким, однако стандартный подход с MVC обеспечивает более понятный (документированный, предсказуемый) workflow приложения для новых разработчиков.

before/after action — оборачивает все методы контроллера сразу — позволяет ли вообще пропустить выполнение экшена? — позволяет ли подменить результат экшена?

Я думаю, можно закончить обсуждение, спасибо) Я понял слабые стороны контроллера в MVC, согласен с аргументами

В приведенном выше примере декоратор так же обернет только метод, возвращающий коллекцию других методов. Да, можно таким образом подменить результат экшна (выбрать нужную функцию и декорировать ее), можно отменить выполнение (подменив на пустую функцию), но тут уже серьезной логикой в роутере попахивает :) Вариант без наследования контроллера и именованных методов-экшнов выглядит и правда более гибким, однако стандартный подход с MVC обеспечивает более понятный (документированный, предсказуемый) workflow приложения для новых разработчиков.

Видимо, мы по-разному представляем себе детали реализации этого гипотетического контроллера.

Видимо, мы по-разному представляем себе детали реализации этого гипотетического контроллера.

А можно поподробнее свое видение?

Я думаю, можно закончить обсуждение, спасибо) Я понял слабые стороны контроллера в MVC, согласен с аргументами

ну вроде на смену MVC приходит mvvm

каким образом корутины проблемы синхронизации решают?

А можно поподробнее свое видение?

Ну, допустим Router( Route(URL, func), ... )

ну вроде на смену MVC приходит mvvm

MVVM в веб — это как?

ну вроде на смену MVC приходит mvvm

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

каким образом корутины проблемы синхронизации решают?

В каналах и акторах есть неблокирующие очереди, например.

каким образом корутины проблемы синхронизации решают?

они не решают, нет таблетки от всех болезней, это просто болле элегантное решение

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

вы таки правы сударь!

блокингкью есть и без них

блокингкью есть и без них

Очередь Елизарова должна быть быстрее

чувак говорит что рейскондишен решается корутинами если я правильн понял)

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

Да можно много разных фоновых задач придумать, которые будут работать в своих потоках, не завися от других. С тем же GUI в джаве уже давно работают, фоновые процессы на другие потоки переносят, результат работы в GUI поток возвращают, и все это не блокирая сам GUI поток. Примеры можно понаходить для разных GUI API, таких как awt, swt, JavaFX, Android.

а разве там под капотом не джавовская блокингкью?

чувак говорит что рейскондишен решается корутинами если я правильн понял)

Не самими корутинами, но Kotlinx.coroutines

Да можно много разных фоновых задач придумать, которые будут работать в своих потоках, не завися от других. С тем же GUI в джаве уже давно работают, фоновые процессы на другие потоки переносят, результат работы в GUI поток возвращают, и все это не блокирая сам GUI поток. Примеры можно понаходить для разных GUI API, таких как awt, swt, JavaFX, Android.

1) awt не имеет такой фигни 2) в JavaFX костыль

а разве там под капотом не джавовская блокингкью?

Конечно нет

а я почему то так думал(

Ну, допустим Router( Route(URL, func), ... )

Практически так, я представлял еще более упрощенно, не как коллекцию объектов Route, а как коллекцию пар ключ-значение (что не принципиально)

Да можно много разных фоновых задач придумать, которые будут работать в своих потоках, не завися от других. С тем же GUI в джаве уже давно работают, фоновые процессы на другие потоки переносят, результат работы в GUI поток возвращают, и все это не блокирая сам GUI поток. Примеры можно понаходить для разных GUI API, таких как awt, swt, JavaFX, Android.

корунтины это не новое, а переосознаное старое, их проще юзать, код более читабельней

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

я описал конкретную ситуацию с GUI

корунтины решают проблему, потоки -нет

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

да и это обсуждалось, посмотрите доклады Елизарова, и станет все ясней

Корунтины это проще, удобней, меньше ресурсов

ребят, можно тупой немного вопрос: есть в gradle-kotlin dsl вот такой сеттер public void setApplicationDefaultJvmArgs(Iterable<String> applicationDefaultJvmArgs) { this.applicationDefaultJvmArgs = applicationDefaultJvmArgs; } вот так applicationDefaultJvmArgs = [""] говорит не правильно, а как?

Спасибо, я их смотрел. Корутины не дешевле потоков, когда гарантированно придётся использовать разные потоки. Но всё ещё удобнее, само собой.

причём всякие kotlin.collections.arrayListOf() - а) не доступен и б) ну как-то не очень смотрится

Спасибо, я их смотрел. Корутины не дешевле потоков, когда гарантированно придётся использовать разные потоки. Но всё ещё удобнее, само собой.

стек, собственая память под обекты, сколько кушает?

Спасибо, я их смотрел. Корутины не дешевле потоков, когда гарантированно придётся использовать разные потоки. Но всё ещё удобнее, само собой.

как это не дешевле потоков?

причём всякие kotlin.collections.arrayListOf() - а) не доступен и б) ну как-то не очень смотрится

arrayListOf<String?)

создать 2 потока и создать 2 корутины - это вообще как небо и земля

arrayListOf<String> ()

arrayListOf<String> ()

так я же написал, не доступен сам метод, пакет kotlin.collections в гредл не прокидывается

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

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

ну сихнатура метода указывает что принимается итератор, зачастую это масивы\колекции

Array

пробуй

не, тоже красный

Правильно. Ещё раз -- у нас есть UI-поток, который нельзя надолго блокировать, и есть сложная на процессор операция / синхронный ввод-вывод. сделать это асинхронно на одном потоке у вас не получится, вам в любом случае нужно поднимать фоновый поток из пула. а поверх него разворачивать корутины и синхронизировать её с корутиной в основном потоке. Что именно у вас здесь дешевле выходит?

не, тоже красный

он может быть красным, пробуй собрать

он может быть красным, пробуй собрать

build.gradle.kts:17:40: Unresolved reference: Array

Правильно. Ещё раз -- у нас есть UI-поток, который нельзя надолго блокировать, и есть сложная на процессор операция / синхронный ввод-вывод. сделать это асинхронно на одном потоке у вас не получится, вам в любом случае нужно поднимать фоновый поток из пула. а поверх него разворачивать корутины и синхронизировать её с корутиной в основном потоке. Что именно у вас здесь дешевле выходит?

есть спецалный билдер async

build.gradle.kts:17:40: Unresolved reference: Array

тогда да, просто подержка котлин дсл хромает

тут я не помогу

есть спецалный билдер async

Я в курсе. Он какое отношение к вопросу имеет?

Правильно. Ещё раз -- у нас есть UI-поток, который нельзя надолго блокировать, и есть сложная на процессор операция / синхронный ввод-вывод. сделать это асинхронно на одном потоке у вас не получится, вам в любом случае нужно поднимать фоновый поток из пула. а поверх него разворачивать корутины и синхронизировать её с корутиной в основном потоке. Что именно у вас здесь дешевле выходит?

с блокирующим IO вообще ничего не сделаешь. Максимум - это выделить отдельный контекст на котором будут запускаться все блокирующие операции

как Елизаров завещал

Правильно. Ещё раз -- у нас есть UI-поток, который нельзя надолго блокировать, и есть сложная на процессор операция / синхронный ввод-вывод. сделать это асинхронно на одном потоке у вас не получится, вам в любом случае нужно поднимать фоновый поток из пула. а поверх него разворачивать корутины и синхронизировать её с корутиной в основном потоке. Что именно у вас здесь дешевле выходит?

есть специальная фигня как пулл, по умолчанию CommonPool, она зачастую сама разлут, если нет берете другой пул который вам подойдет или создаете свой. Комон пулл узает несколько потоков не обязательно один

Ровно об этом я и говорю -- при надобности уйти из UI в бекграунд корутины волшебным образом не делают всё дешевле.

Я в курсе. Он какое отношение к вопросу имеет?

вы думае что запущеные корунтины обязаны выполнятся на одном потоки - это не так

вы думае что запущеные корунтины обязаны выполнятся на одном потоки - это не так

Перечитайте мои сообщения, пожалуйста.

Ровно об этом я и говорю -- при надобности уйти из UI в бекграунд корутины волшебным образом не делают всё дешевле.

вы издеваетесь? 2-4 мг это только стек для потока

я чесно не поню утверждать не буду но примерно так, еще своя память выеляется

вы издеваетесь? 2-4 мг это только стек для потока

Я понять не могу -- у вас есть две корутины, которые выполняются на двух разных потоках -- одна в UI, вторая в CommonPool -- у вас и между ними переключение бесплатное просто потому, что они корутины?

Ровно об этом я и говорю -- при надобности уйти из UI в бекграунд корутины волшебным образом не делают всё дешевле.

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

корунтина это блок кода который может выполнен на любом потоке. Им без разницы

Я понять не могу -- у вас есть две корутины, которые выполняются на двух разных потоках -- одна в UI, вторая в CommonPool -- у вас и между ними переключение бесплатное просто потому, что они корутины?

нет, а разве нативные потоки бесплатно переключаются? сколько у вас ядер ? сколько потоков? я про процессор

Я понять не могу -- у вас есть две корутины, которые выполняются на двух разных потоках -- одна в UI, вторая в CommonPool -- у вас и между ними переключение бесплатное просто потому, что они корутины?

а про какое переключение идёт речь для 2х корутин и 2х потоков?

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

Я с этим и не спорю.

я бы просто понял если была бы 1 корутина и 2 потока

или наоборот

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

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

об это говорилось в докладе, не конкретно про этот случай, обговариловалось такие блокировки, но товарищь все смотрел

а дальше что-то вроде "товарищ Executer продолжи вот этот блок кода с такой-то чиселки, а там блок кода - это свитч от этого числа"

Я понять не могу -- у вас есть две корутины, которые выполняются на двух разных потоках -- одна в UI, вторая в CommonPool -- у вас и между ними переключение бесплатное просто потому, что они корутины?

ах да корунтины превращаются в обычные Future, и их юзаю в джаве, а от потоков пытаются уйти

Так, давайте ещё раз -- Богдан отметил, что корутины лучше и дешевле, чем потоки, я отметил, что в случае с необходимостью выполнить блокирующую операцию всё равно будет CommonPool и затраты на переключение потоков, потому волшебства нету и нету безусловного "дешевле". О чём спор, раз тут все такие умные, что сарказмом разбрасываются?

а дальше что-то вроде "товарищ Executer продолжи вот этот блок кода с такой-то чиселки, а там блок кода - это свитч от этого числа"

конеынй автомат)

Так, давайте ещё раз -- Богдан отметил, что корутины лучше и дешевле, чем потоки, я отметил, что в случае с необходимостью выполнить блокирующую операцию всё равно будет CommonPool и затраты на переключение потоков, потому волшебства нету и нету безусловного "дешевле". О чём спор, раз тут все такие умные, что сарказмом разбрасываются?

ну не обязательно же коммон пул

Так, давайте ещё раз -- Богдан отметил, что корутины лучше и дешевле, чем потоки, я отметил, что в случае с необходимостью выполнить блокирующую операцию всё равно будет CommonPool и затраты на переключение потоков, потому волшебства нету и нету безусловного "дешевле". О чём спор, раз тут все такие умные, что сарказмом разбрасываются?

это не нативное переключения потоков, но да когда у вас тормозит память или диск а процесор ждет он будет ждать в любом случае

Не обязательно, конечно. Всё ещё другой поток, откуда он возьмётся -- CommonPool, свой экзекьютор -- не важно.

Не обязательно, конечно. Всё ещё другой поток, откуда он возьмётся -- CommonPool, свой экзекьютор -- не важно.

вот для этого и существуют програмисты

это не нативное переключения потоков, но да когда у вас тормозит память или диск а процесор ждет он будет ждать в любом случае

Почему не нативное? Я вот и пытаюсь понять, куда девается нативное переключение потоков, когда есть несколько потоков.

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

вот для этого и существуют програмисты

чтобы потоки из воздуха делать? =)

Почему не нативное? Я вот и пытаюсь понять, куда девается нативное переключение потоков, когда есть несколько потоков.

ну скажем там есть куча фигни в процессоре, ванги манги

ну скажем там есть куча фигни в процессоре, ванги манги

Хорошо, я попробую поставить иначе вопрос, а то ну совсем никак не получается диалог -- вы о чём-то своём. Чем async(CommonPool) { ... } .await() дешевле, чем фьючеры с экзекьютором?

Хорошо, я попробую поставить иначе вопрос, а то ну совсем никак не получается диалог -- вы о чём-то своём. Чем async(CommonPool) { ... } .await() дешевле, чем фьючеры с экзекьютором?

да если у вас будет много Future

new Future новый обект

лямба новый обект

в случае с корунтинами там меншь

Почему не нативное? Я вот и пытаюсь понять, куда девается нативное переключение потоков, когда есть несколько потоков.

стоп, ну тут оба правы же, до suspend point всё выполняет один поток, как только начали чего-то ждать асинхронно - тут тред вернули в пулл, потом когда дождались взяли из пула тред, каким он будет - хз

псали же конечный автомат

стоп, ну тут оба правы же, до suspend point всё выполняет один поток, как только начали чего-то ждать асинхронно - тут тред вернули в пулл, потом когда дождались взяли из пула тред, каким он будет - хз

комон пул это не один поток, реализацию нужно смотреть

я пока в коде не ковырялся

но да если слишком много корунтин, даже которые ничего не блочат

комон пул это не один поток, реализацию нужно смотреть

омг, где я написал что пулл - это один поток?

это может замедить

омг, где я написал что пулл - это один поток?

ну я не так понял

сорян