Size: a a a

Kotlin Community

2020 June 11

LS

Lev Shagalov in Kotlin Community
Alexander Nozik
Ну надо бы остальные статьи тоже почитать, а еще лучше лекцию послушать. Я тебе скидывал вроде.
Я все читал и смотрел что ты мне скидывал
источник

AN

Alexander Nozik in Kotlin Community
Lev Shagalov
Я правильно понимаю:
1. Запуск withContext(this.coroutineContext){ ... } - это ничего не дает, выполнение кода без такой обертки абсолютно идентично выполнению с такой оберткой.
2. launch и async в случае работы в одном потоке запустят джоб не сразу, а вероятно после следующей точки остановки? А вот если диспатчер многопоточный - то launch и async запустятся сразу, параллельно (ну если будет свободный тред)
4. Если надо дождаться корутины launch/async - используем join/await соответственно. Эти методы идентичны по смыслу, просто второй вернет результат
4.1. join/await - блокируют исполнение кода (suspend) но не поток.
4.2. Если 4 верно, то зачем тогда launch-join? Был бы async-await, ну вернет он Unit и чего?
5. runBlocking {  launch {  }  } - заблокирует поток то тех пор, пока launch не завершится. Т.к. внешний скоуп будет ждать всех дочерних. То есть это можно использовать для записи например в базу. В случае когда надо записать но данные потом не потребуются, можно использовать launch понимаю что если он завершится с ошибкой, то внешний try ее словит. Типа fire and forget но выполнения все же дождется.
6. withContext суспендит код пока не выполнит тело в другом контексте (вероятно обычно это используется для смены потока, для shared mutable state наверно. А для чего еще кроме смены потока?)
2 - нет. Запустят они его сразу. Порядок выполнения зависит от диспатчера. Вообще, хороший вопрос, что будет выполняться сначала. То, что внутри launch или то, что сразу за ним, но это на самом деле не важно, потому что порядок сохраняется внутри одной корутины, а launch порождает новую
источник

AN

Alexander Nozik in Kotlin Community
Lev Shagalov
Я правильно понимаю:
1. Запуск withContext(this.coroutineContext){ ... } - это ничего не дает, выполнение кода без такой обертки абсолютно идентично выполнению с такой оберткой.
2. launch и async в случае работы в одном потоке запустят джоб не сразу, а вероятно после следующей точки остановки? А вот если диспатчер многопоточный - то launch и async запустятся сразу, параллельно (ну если будет свободный тред)
4. Если надо дождаться корутины launch/async - используем join/await соответственно. Эти методы идентичны по смыслу, просто второй вернет результат
4.1. join/await - блокируют исполнение кода (suspend) но не поток.
4.2. Если 4 верно, то зачем тогда launch-join? Был бы async-await, ну вернет он Unit и чего?
5. runBlocking {  launch {  }  } - заблокирует поток то тех пор, пока launch не завершится. Т.к. внешний скоуп будет ждать всех дочерних. То есть это можно использовать для записи например в базу. В случае когда надо записать но данные потом не потребуются, можно использовать launch понимаю что если он завершится с ошибкой, то внешний try ее словит. Типа fire and forget но выполнения все же дождется.
6. withContext суспендит код пока не выполнит тело в другом контексте (вероятно обычно это используется для смены потока, для shared mutable state наверно. А для чего еще кроме смены потока?)
4.2 Потому что Deferred  наследует Job. У него есть и join и await.
источник

LS

Lev Shagalov in Kotlin Community
4.2 Зачем делать и то и то? Был бы Deferred, какая разница что он вернет Unit?
источник

LS

Lev Shagalov in Kotlin Community
Alexander Nozik
2 - нет. Запустят они его сразу. Порядок выполнения зависит от диспатчера. Вообще, хороший вопрос, что будет выполняться сначала. То, что внутри launch или то, что сразу за ним, но это на самом деле не важно, потому что порядок сохраняется внутри одной корутины, а launch порождает новую
Я про один поток. Если все произошло в одном потоке. Что будет первым? Т.к. launch не suspended то я предположил что он не будет останавливать исполнение внешнего кода из-за корутины.
источник

AN

Alexander Nozik in Kotlin Community
Lev Shagalov
4.2 Зачем делать и то и то? Был бы Deferred, какая разница что он вернет Unit?
Ну потому что с точки зрения API так удобно. Меньше мест, где можно ошибиться
источник

AN

Alexander Nozik in Kotlin Community
Lev Shagalov
Я про один поток. Если все произошло в одном потоке. Что будет первым? Т.к. launch не suspended то я предположил что он не будет останавливать исполнение внешнего кода из-за корутины.
ну проверь. Я думаю, что в общем случае порядок раскладки по треду не определен
источник

LS

Lev Shagalov in Kotlin Community
Alexander Nozik
Ну потому что с точки зрения API так удобно. Меньше мест, где можно ошибиться
Не очень убедительно, помоему как раз таки мест больше, методов то больше. Ладно, потом докопаюсь с этим.
источник

LS

Lev Shagalov in Kotlin Community
Roman Elizarov
На какой середине?
Я наверно что то пропускаю, но я не вижу четкого описания почему есть и скоуп и контекст. Почему не оставить только контекст?

The intended purpose of CoroutineScope receiver in launch and in all the other coroutine builders is to reference a scope in which new coroutine is launched.
Почему не использовать контекст вместо скоупа в этом случае?

Since the context and the scope are materially the same thing...
Если одно и тоже - зачем разделять?
источник

RE

Roman Elizarov in Kotlin Community
Так в самом начале написано. Для людей, в первую очередь. Чтобы когда вижешь в коде ссылку на scope или context было понятно зачем здесь этот параметр (и чтобы не нужно было доку читать)
источник

LS

Lev Shagalov in Kotlin Community
А чем отличаются то? Написано что назначением. Но что именно за назначение?
источник

RE

Roman Elizarov in Kotlin Community
Ни и еще чтобы удобно разные полезные методы развесить. На CoroutineContext много методов, его не удобнмо в свое коде иметь как receiver, а на scope только небольшое число особенно отобранных (в т.ч. всё coroutine builder) — его удобно иметь как this.
источник

RE

Roman Elizarov in Kotlin Community
Так как раз статья об этом scope — чтобы запускать новые корутины, context чтобы передавать им дополнительные контекстные параметры.
источник

LS

Lev Shagalov in Kotlin Community
А... То есть теоретически можно было бы оставить только контекст, но это было бы неудобно из-за кучи методов?
источник

RE

Roman Elizarov in Kotlin Community
Была бы путаница в API. Но, кстати, так было до structured сoncurrency в пре 1.0 времена: https://medium.com/@elizarov/structured-concurrency-722d765aa952
источник

BP

Bogdan Panchenko in Kotlin Community
Lev Shagalov
Я про один поток. Если все произошло в одном потоке. Что будет первым? Т.к. launch не suspended то я предположил что он не будет останавливать исполнение внешнего кода из-за корутины.
launch - фоновая работа, async - выполнить вычисления "паралельно" и дождаться их при вызове await.
источник

LS

Lev Shagalov in Kotlin Community
Спасибо, теперь понятно почему есть скоуп и контекст
источник

LS

Lev Shagalov in Kotlin Community
Bogdan Panchenko
launch - фоновая работа, async - выполнить вычисления "паралельно" и дождаться их при вызове await.
Я думал единственное отличие в том, что async может вернуть результат. А остальное одинаково.
источник

V

Vladimir in Kotlin Community
Lev Shagalov
Я думал единственное отличие в том, что async может вернуть результат. А остальное одинаково.
и я так думал
источник

LS

Lev Shagalov in Kotlin Community
Bogdan Panchenko
launch - фоновая работа, async - выполнить вычисления "паралельно" и дождаться их при вызове await.
Поясните
источник