https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
u

4ntoine

07/04/2019, 7:39 AM
Hey, guys. Is there multiplatform
lock
or
synchronized
in Kotlin? https://stackoverflow.com/questions/56882860/is-there-multiplatform-lock-on-kotlin
u

4ntoine

07/04/2019, 7:46 AM
afaik coroutines library increases disk fooprint so it’s undesired. Anything else?
e

elizarov

07/04/2019, 7:47 AM
There’s nothing else yet, but is planned as a part of
kotlinx.atomicfu
library. Btw, what kind of “disk footprint” are you measuring?
u

4ntoine

07/04/2019, 7:49 AM
Hi, Roman. I’m talking about jar size ~ 1.3Mb https://mvnrepository.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core/1.3.0-M2 looks a bit scary
e

elizarov

07/04/2019, 7:49 AM
Are you using any kind of optimizer? ProGuard, R8?
u

4ntoine

07/04/2019, 7:53 AM
We’re working on some library (currently android-only) and it’s undesired to add heavy deps without serious reason. We do understand our partners that are using it in end-user apps can use Proguard and shrink unused, but first i want to investigate alternatives
Any estimation on when
synchronized
will be removed from common lib? Are we safe to use it for some time at least?
e

elizarov

07/04/2019, 7:58 AM
If you are writing Android/JVM lib you can just use
synchronized
. It is a part of a stable Kotlin API and there is no plan to remove it.
u

4ntoine

07/04/2019, 8:01 AM
We’re writing multiplatform library, but the only implementation for now (that is going to be released for production) is JVM/Android. So ideally we would use some multiplatform approach that will not be obsolete soon. For now it works for us with
synchronized
, but looking for long-time (or just “proper”) solution
What disk footprint can we expect when shrinked with Proguard/r8 if using this mutex lock from coroutines core lib only?
e

elizarov

07/04/2019, 8:08 AM
Right now coroutines add ~150kb in debug mode (full symbols) and we’re looking to get it below < 100kb by turning off various debug & high-scale features. I don’t know how much that would translate with obfuscation and stripped debug data.
Note, though, that
Mutex
only works if you are using coroutines — it is a lock that suspends a coroutine, not blocks a thread.
g

gildor

07/04/2019, 8:39 AM
One more reason to extract channels or/and flow API from core (yes I again talking about this). Or even more fine grained splitting
u

4ntoine

07/04/2019, 12:02 PM
@elizarov Could you please explain how you measured 150Kb for kotlinx coroutines, is it jar size? Not sure how 150kb and 1.3Mb correlates.. Sounds great
e

elizarov

07/04/2019, 12:03 PM
It depends on what features you use. Many of them (like channels, flows) are incremental — you only get them if you use them (optimizers remove unused code)
u

4ntoine

07/04/2019, 12:03 PM
oh, it’s size after shrinking. Thanks for clarification
e

elizarov

07/04/2019, 12:04 PM
(but w/o obsufcation. It will be much smaller then)
l

louiscad

07/04/2019, 12:07 PM
Would be interesting to know after obfuscation as shrinking something like
kotlinx.coroutines.channels.Channel
can become 5 times smaller in terms of characters count:
a.a.a.a
, and so does all the bytecode.
b

basher

07/04/2019, 12:36 PM
👍 1
u

4ntoine

07/04/2019, 12:52 PM
@basher Looks promising, thanks for the link
👍 1
e

elizarov

07/04/2019, 12:56 PM
Spinlock-only impl on native 😞
b

basher

07/04/2019, 2:22 PM
Spinlock on mingw. NSRecursiveLock on iOS. I think @kpgalligan might be looking at refactoring so that locks have to be closed; then they can use pthread_lock. Issue right now is that the current implementation relies on iOS and JVM objects being able to tie in to object lifetime automatically (I.e. destroy resources when objects are collected). Can't do that on other platforms, so everything else gets a spinlock for now.
k

kpgalligan

07/04/2019, 2:25 PM
I’m in process on that update. The lock is less of an issue that I rewrote the collections to use C++ collections directly rather than native atomics, but the “relaxed mode” commits on native have kind of put stately rewrites on the back burner, TBH. However, yes, the plan is to add a close and use pthread_lock on all native. More like this
👍 1
expect class Lock() { fun lock() fun unlock() fun tryLock(): Boolean fun close() }
Spinlock, yeah. That darn windows. Maybe a less ambitious stately update in the near term, or pull collections out into a separate lib (that actually sounds like a good idea)
👍 1
Moved. Collections now a separate module. Native lock collapsed so all instances use pthread and need ‘close’ called. Still a WIP, but simpler build for sure (and need to deploy windows): https://github.com/touchlab/Stately/blob/master/stately/src/nativeCommonMain/kotlin/co/touchlab/stately/concurrency/Lock.kt
a

Arkadii Ivanov

07/06/2019, 2:04 PM
@kpgalligan perhaps
arena
,
attr
and
mutex
fields should be private as they are implementation details 😀
k

kpgalligan

07/06/2019, 2:07 PM
Like I said, work in progress. The issue is doing close as an extension. The idea is I want to see if we use typealias for expect/actual, can we make the library be invisible to one side. In this case the JVM. I assume that will also take some proguard to strip the unnecessary definitions.
On the lock, the JVM has no
close
, so adding that to
Lock
means I can no longer use typealias
The libraries I’m building have a strong native mobile and Android lean to them, so if I can, I want to impact the JVM side minimally.
If typealias doesn’t make the JVM side invisible, or maybe if it’s not worth it, I’d move
close
to
Lock
, then yes, the rest would be internal (or hide them a different way)
(sort of) fixed it
a

Arkadii Ivanov

07/06/2019, 4:19 PM
Looks better)
90 Views