Телеграмм чат группы KotlinMoscow страница 217

Потомки не роняют предка, но если предок закрыт, потомки не утекают

15:30пожаловаться

AN

Есть функция с такой сигнатурой (сигнатуру менять нельзя):

fun method(): ServiceCall<Requst, Response>

Задача: заиметь возможность вызывать suspend функции внутри этого метода.
Поэтому и написали билдер, что выше скинул. Теперь вот так

fun method(): ServiceCall<Requst, Response> = serviceCall {
  // this I can call suspend method
}

Если serviceCall будет как CoroutineScope.serviceCall, то как мне его вызывать, если класс, который содержит method совсем не CoroutineScope 🙁

Явно притащить. scope.seriviceCall(...)

15:31пожаловаться

RI

Ну если там суперивизоры проложены почему нет?

Ну так можно конечно, но где в том примере SupervisorJob?

15:31пожаловаться

AN

Ну так можно конечно, но где в том примере SupervisorJob?

supervisorScope{ serviceCall(...)}

15:32пожаловаться

RI

Вполне. Можно даже сам AppState сделать скоупом

Я думал мы про этот пример говорим https://t.me/KotlinMoscow/5917

Alexander Nozik in Kotlin Moscow

15:33пожаловаться

AN

Вполне. Можно даже сам AppState сделать скоупом

Я думал мы про этот пример говорим https://t.me/KotlinMoscow/5917

Alexander Nozik in Kotlin Moscow

Не, если один скоуп на все приложение, то нормально. Но я бы все равно сделал val scope = GlobalScope.coroutineScope() или как там пустой дочерний скоуп создается

15:34пожаловаться

SM

Явно притащить. scope.seriviceCall(...)

Возвращаюсь к вопросу откуда взять scope? Сделать свойством класса и в конструкторе инициализировать один раз? Учитывая, что method это хендлер отдельного HTTP запроса, и я пока не могу осознать зачем мне нужен единый скоуп для независимых запросов. Как-то это контринтуитивно для меня пока.

15:35пожаловаться

RI

Возвращаюсь к вопросу откуда взять scope? Сделать свойством класса и в конструкторе инициализировать один раз? Учитывая, что method это хендлер отдельного HTTP запроса, и я пока не могу осознать зачем мне нужен единый скоуп для независимых запросов. Как-то это контринтуитивно для меня пока.

Если ли какая-то сущность выше по стеку которая делает сервис колы и может упасть/отмениться?

15:37пожаловаться

AN

Kotlin Coroutines have a context. There is a also a concept of coroutine scope that looks very much like a context. What’s the difference?

Возвращаюсь к вопросу откуда взять scope? Сделать свойством класса и в конструкторе инициализировать один раз? Учитывая, что method это хендлер отдельного HTTP запроса, и я пока не могу осознать зачем мне нужен единый скоуп для независимых запросов. Как-то это контринтуитивно для меня пока.

Ну база вот тут: https://medium.com/@elizarov/coroutine-context-and-scope-c8b255d59055

Medium

Coroutine Context and Scope

15:37пожаловаться

AN

Если ли какая-то сущность выше по стеку которая делает сервис колы и может упасть/отмениться?

правильный вопрос

15:37пожаловаться

SM

Kotlin Coroutines have a context. There is a also a concept of coroutine scope that looks very much like a context. What’s the difference?

Ну база вот тут: https://medium.com/@elizarov/coroutine-context-and-scope-c8b255d59055

Medium

Coroutine Context and Scope

Так не один раз уже прочитал. И вторую его статью на тему Global и structured concurrency. Видимо пока не до конца зашло 🙂

15:38пожаловаться

RI

Потомки не роняют предка, но если предок закрыт, потомки не утекают

Кстати я что-то пропустил момент что в SupervisorJob потомки не убивают предка, спасибо, буду знать.

15:38пожаловаться

AN

Так не один раз уже прочитал. И вторую его статью на тему Global и structured concurrency. Видимо пока не до конца зашло 🙂

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

15:39пожаловаться

SM

Если ли какая-то сущность выше по стеку которая делает сервис колы и может упасть/отмениться?

По идее нет. Это базовый класс сервиса (аля контроллер) с которого всё начинается. Точнее внутри у фреймворка там конечно начинается гораздо раньше, но для обычного разработчика это точка старта

15:39пожаловаться

AN

По идее нет. Это базовый класс сервиса (аля контроллер) с которого всё начинается. Точнее внутри у фреймворка там конечно начинается гораздо раньше, но для обычного разработчика это точка старта

Может приложение закрыться пока эта штука работает?

15:40пожаловаться

SM

Может приложение закрыться пока эта штука работает?

Если рассматривать грейсфул, то по идее нет. В рамках шатдауна остановка начинается именна с него, а потом останавливаются уже какие-то низкоуровневые компоненты типа коннекторов к ресурсам, в конце концов даунится кластер и потом приложений завершается

15:43пожаловаться

RI

Ну скорее всего запрос может упасть по таймауту, т.е. в скоупе запроса нужно создать скоуп для корутин.

15:44пожаловаться

AN

Если рассматривать грейсфул, то по идее нет. В рамках шатдауна остановка начинается именна с него, а потом останавливаются уже какие-то низкоуровневые компоненты типа коннекторов к ресурсам, в конце концов даунится кластер и потом приложений завершается

Просто структурная кокуррентность как раз про это. Если где-то что-то закрывается извне, то процесс без предка утекает и лучше, чтобы был предок, который автоматом закроет все запросы. Опять же, это не догма.

15:44пожаловаться

RI

Если старые добрые сервлеты то это фильтр который кладет скоуп в тред локал. Если новые flux то там есть контекст для этого

15:45пожаловаться

SM

Если старые добрые сервлеты то это фильтр который кладет скоуп в тред локал. Если новые flux то там есть контекст для этого

Отличная идея свети к сервлетам 🙂 Если я положу скоуп в контекст запроса, то что мне это даст? Вместе со смертью запроса (предположим это объект класса HTTPServletRequest) умрёт CoroutineScope, что приведёт к отмене всех привязанных к этому скоупу корутин? Я верно понял?