Size: a a a

Kotlin Community

2020 September 03

AM

Andrew Mikhaylov in Kotlin Community
Там есть отдельная веточка про многопоточность native-mt, но оно не в релизе, да.
источник

IO

Iaroslav Orlov in Kotlin Community
вообще, лично меня заморозка бесит.

язык мутабельный
@
рантайм нет

лучше бы просто чистый язык сделали
источник

IO

Iaroslav Orlov in Kotlin Community
Iaroslav Orlov
вообще, лично меня заморозка бесит.

язык мутабельный
@
рантайм нет

лучше бы просто чистый язык сделали
pro tip: just invalidate var keyword in native targets
источник

IO

Iaroslav Orlov in Kotlin Community
Bogdan Panchenko
В данной реализации да
странно. пишут, что корутины на нейтиве используют атомики для внутренней синхронизации. ну и чего тогда каналы не починили (
источник

BP

Bogdan Panchenko in Kotlin Community
Iaroslav Orlov
странно. пишут, что корутины на нейтиве используют атомики для внутренней синхронизации. ну и чего тогда каналы не починили (
Смотря какие атомики. Нейтивские ? И как это должно было починить каналы если канал это блокировка по сути
источник

IO

Iaroslav Orlov in Kotlin Community
ну вот конкретная проблема - внутри канала есть мутабельная хеш мапа. почему ее не сделали атомарной, если им ничего не мешает использовать атомики где-то внутри
источник

BP

Bogdan Panchenko in Kotlin Community
Iaroslav Orlov
ну вот конкретная проблема - внутри канала есть мутабельная хеш мапа. почему ее не сделали атомарной, если им ничего не мешает использовать атомики где-то внутри
Эмми. Атомик следит только за изменяемой переменной, а не за ее состоянием, но есть хешмапы с какаренси но на джвм, на нейтиве хз
источник

IO

Iaroslav Orlov in Kotlin Community
Bogdan Panchenko
Эмми. Атомик следит только за изменяемой переменной, а не за ее состоянием, но есть хешмапы с какаренси но на джвм, на нейтиве хз
эх. ну в таком случае только костылить изоляцию, как у меня
источник

BP

Bogdan Panchenko in Kotlin Community
Iaroslav Orlov
ну вот конкретная проблема - внутри канала есть мутабельная хеш мапа. почему ее не сделали атомарной, если им ничего не мешает использовать атомики где-то внутри
Ну в целом смысл канала теряется на однопоточке, тут более подробней может Александр рассказать
источник

IO

Iaroslav Orlov in Kotlin Community
Iaroslav Orlov
эх. ну в таком случае только костылить изоляцию, как у меня
это вообще единственный способ сделать мутабельный субграф, видимо
источник

BP

Bogdan Panchenko in Kotlin Community
Iaroslav Orlov
это вообще единственный способ сделать мутабельный субграф, видимо
Делайте PR 😊
источник

IO

Iaroslav Orlov in Kotlin Community
Bogdan Panchenko
Делайте PR 😊
да это не новая идея
источник

IO

Iaroslav Orlov in Kotlin Community
и у нее много косяков
источник

AM

Andrew Mikhaylov in Kotlin Community
Bogdan Panchenko
Ну в целом смысл канала теряется на однопоточке, тут более подробней может Александр рассказать
Чойта теряется? Каналы суть механизм коммуникации корутин, и их полезность не зависит от того, однопоточный под ними диспатчер или нет.
источник

IO

Iaroslav Orlov in Kotlin Community
Iaroslav Orlov
и у нее много косяков
больная небезопасная concurrency уж точно лучше
источник

BP

Bogdan Panchenko in Kotlin Community
Andrew Mikhaylov
Чойта теряется? Каналы суть механизм коммуникации корутин, и их полезность не зависит от того, однопоточный под ними диспатчер или нет.
Ну это уже наверное в целом про при приложения. Скорей всего у тебя везде будут последовательные вызовы, особенно на нейтиве, где привыкли экономить
источник
2020 September 04

ПФ

Паша Финкельштейн... in Kotlin Community
Ruslan Ibragimov
Сейчас опциональная да, но все идет к тому что они везде пролезают и будут куда более востребованы чем работа с thread api. И соответсвенно код становится более вербозный. Я говорю о том что этот дефолт был хорош на старте, но сейчас хочется сделать обратный.

Есть три вида функций:

1. suspend
2. regular
3. blocking

В языке сейчас есть средства только чтобы пометить suspend. И таких функций становится большинство. Соотвественно если теперь suspend это норма, то хотелось бы чтобы

1. suspend fun -> fun
2. regular (fun) -> nosuspend fun (для оптизиций, можно и не вводить такой keyword)
3. blocking (fun) -> blocking fun - те функции которые по каким-то причинам блокируют поток, и их важно не вызвать на основном пуле
Что делать с библиотеками? Допустим, я работаю с хадупом. Там полностью свой слой io, не завязанный на обычный джавовый. Как это понять котлину?
источник

RI

Ruslan Ibragimov in Kotlin Community
Паша Финкельштейн
Что делать с библиотеками? Допустим, я работаю с хадупом. Там полностью свой слой io, не завязанный на обычный джавовый. Как это понять котлину?
Так же как сейчас с null из джавы - считаем что функция regular. Можно добавить аннотаций (те которые XML), или просто обернуть в inline функцию и пометить как blocking
источник

AN

Alexander Nozik in Kotlin Community
Я кстати не согласен с тем, что весь код становится suspend. В логике приложения - возможно. Но в библиотеке точно нет. В библиотеке suspend - это наоборот хороший маркер того, что имеет место длительное выполнение. Возможно можно включить какие-то флаги, которые определенные файлы сразу размечают полностью как suspend, но идея делать это поведением по-умолчанию мне кажется не очень.
источник

AM

Andrew Mikhaylov in Kotlin Community
Alexander Nozik
Я кстати не согласен с тем, что весь код становится suspend. В логике приложения - возможно. Но в библиотеке точно нет. В библиотеке suspend - это наоборот хороший маркер того, что имеет место длительное выполнение. Возможно можно включить какие-то флаги, которые определенные файлы сразу размечают полностью как suspend, но идея делать это поведением по-умолчанию мне кажется не очень.
Идея включать это флагами для отдельных частей кода звучит ещё менее хорошей.
источник