В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Kotlin Community

3521 membersпожаловаться на группу
2020 August 01

AN

Alexander Nozik in Kotlin Community
Arkadii Ivanov
Да как же так? Если там стоит Main dispatcher и я на главном потоке отменяю корутину. Как так она может вызваться в следующем фрейме главного потока?
Отмена - это сигнал на отмену. Там нет блокировки и синхронизации. И проблема не в корутинах, а в том, что вообще есть гонка. Ее быть не должно не зависимо от потоков.
источник
21:46пожаловаться#1

AI

Arkadii Ivanov in Kotlin Community
Alexander Nozik
Отмена - это сигнал на отмену. Там нет блокировки и синхронизации. И проблема не в корутинах, а в том, что вообще есть гонка. Ее быть не должно не зависимо от потоков.
Ладно, видимо так работают корутины. Хорошо что я использую Rx, там это гарантируется
источник
21:46пожаловаться#2

AN

Alexander Nozik in Kotlin Community
Arkadii Ivanov
Ладно, видимо так работают корутины. Хорошо что я использую Rx, там это гарантируется
Даже если вы будете писать на тредах interrupt не гарантирует мгновенной отмены. С большими шансами ваш рх выдаст точно такую же ошибку но уже в проде.  У вас ошибка проектирования. Корутины в этом совершенно не виноваты. Моя рекомендация, еще раз, посмотреть, как сделать то же самое без гонки.
источник
21:49пожаловаться#3

AI

Arkadii Ivanov in Kotlin Community
Alexander Nozik
Даже если вы будете писать на тредах interrupt не гарантирует мгновенной отмены. С большими шансами ваш рх выдаст точно такую же ошибку но уже в проде.  У вас ошибка проектирования. Корутины в этом совершенно не виноваты. Моя рекомендация, еще раз, посмотреть, как сделать то же самое без гонки.
Мне кажется мы говорим о разных вещах :-)
источник
21:49пожаловаться#4

AN

Alexander Nozik in Kotlin Community
Arkadii Ivanov
Мне кажется мы говорим о разных вещах :-)
Мы говорим о том, есть ли гарантия того, что что-то отменилось мгновенно после того, как вы послали сигнал на отмену. Нету такой гарантии. Возможно Рх там блокирует поток пока отмена не выполнена, но наличие блокировки - это как бы совсем не есть хорошо.
источник
21:51пожаловаться#5

AI

Arkadii Ivanov in Kotlin Community
Alexander Nozik
Мы говорим о том, есть ли гарантия того, что что-то отменилось мгновенно после того, как вы послали сигнал на отмену. Нету такой гарантии. Возможно Рх там блокирует поток пока отмена не выполнена, но наличие блокировки - это как бы совсем не есть хорошо.
Дело в том что корутина работает на главном потоке. Следовательно она гарантированно suspended, пока выполняется job.cancel(). Далее она должна проснуться, чтоб выполнить collect{}. Получается она просыпается из suspended гарантированного ПОСЛЕ выполнения Job.cancel.
источник
21:52пожаловаться#6

AI

Arkadii Ivanov in Kotlin Community
И вопрос в том, почему она просыпается, если она 100% cancelled
источник
21:53пожаловаться#7

AI

Arkadii Ivanov in Kotlin Community
Если бы там был другой Dispatcher, то не было бы вопросов. А тут Главный. И там всё последовательно, одно после другого.
источник
21:54пожаловаться#8

AN

Alexander Nozik in Kotlin Community
Arkadii Ivanov
Дело в том что корутина работает на главном потоке. Следовательно она гарантированно suspended, пока выполняется job.cancel(). Далее она должна проснуться, чтоб выполнить collect{}. Получается она просыпается из suspended гарантированного ПОСЛЕ выполнения Job.cancel.
Во-первых вы не правы, у корутин свой эвент луп и строить приложение на основе вашего понимания внутренней работы этого лупа - это очень странная идея.
источник
21:54пожаловаться#9

AN

Alexander Nozik in Kotlin Community
Во-вторых вообще закладываться на конкретное поведение диспатчера - плохая идея.
источник
21:55пожаловаться#10

AI

Arkadii Ivanov in Kotlin Community
Я вас понял, спасибо.
источник
21:55пожаловаться#11

AI

Arkadii Ivanov in Kotlin Community
Это многое объясняет.
источник
21:55пожаловаться#12

RI

Ruslan Ibragimov in Kotlin Community
Ох уж этот passive-aggresive rx
источник
21:58пожаловаться#13

AN

Alexander Nozik in Kotlin Community
Ruslan Ibragimov
Ох уж этот passive-aggresive rx
Там не в rx дело.
источник
22:02пожаловаться#14

RI

Ruslan Ibragimov in Kotlin Community
Можно как-то вопроизвести ошибку без андроидовского диспетчера? Не знаю, на newFixedThreadPool?
источник
22:02пожаловаться#15

RI

Ruslan Ibragimov in Kotlin Community
Вполне возможно в диспетчере который android есть твики, о которых ни я, не @noraltavir не знает и которые как раз таки влияют на это поведение
источник
22:04пожаловаться#16

AI

Arkadii Ivanov in Kotlin Community
Ruslan Ibragimov
Ох уж этот passive-aggresive rx
Да брось-те. Мне просто кажется, что какие-то естественные вещи. Потому что job.cancel происходит гарантированно до просыпания корутины. И тут есть happens before. И мне кажется в потрохах должна быть проверка на isActive.
источник
22:04пожаловаться#17

RI

Ruslan Ibragimov in Kotlin Community
Arkadii Ivanov
Да брось-те. Мне просто кажется, что какие-то естественные вещи. Потому что job.cancel происходит гарантированно до просыпания корутины. И тут есть happens before. И мне кажется в потрохах должна быть проверка на isActive.
А если убрать offer? Offer делает рандеву и может разбудить колбек на другой стороне
источник
22:04пожаловаться#18

AN

Alexander Nozik in Kotlin Community
Arkadii Ivanov
Да брось-те. Мне просто кажется, что какие-то естественные вещи. Потому что job.cancel происходит гарантированно до просыпания корутины. И тут есть happens before. И мне кажется в потрохах должна быть проверка на isActive.
happens before это про доступ к памяти. А я уже раз пять сказал, что job.cancel() только выставляет флаг, то, что там крутится в лбюом случае доработает до ближайшей suspension point.
источник
22:05пожаловаться#19

AI

Arkadii Ivanov in Kotlin Community
К примеру в Rx в Observable.subscribe есть проверка на isDisposed. И если вызвать Dispose на одном потоке, и СРАЗУ ПОСЛЕ сделать эмит в этом же кол стеке, то 100% гарантия что айтем не прилетит. А тут такое.
источник
22:05пожаловаться#20