Hey, guys. Is there multiplatform

lock

or

synchronized

in Kotlin? https://stackoverflow.com/questions/56882860/is-there-multiplatform-lock-on-kotlin

afaik coroutines library increases disk fooprint so it’s undesired. Anything else?

There’s nothing else yet, but is planned as a part of

kotlinx.atomicfu

library. Btw, what kind of “disk footprint” are you measuring?

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

Are you using any kind of optimizer? ProGuard, R8?

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

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.

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

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.

One more reason to extract channels or/and flow API from core (yes I again talking about this). Or even more fine grained splitting

@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

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)

oh, it’s size after shrinking. Thanks for clarification

(but w/o obsufcation. It will be much smaller then)

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.

Stately has a mpp lock https://github.com/touchlab/stately

@basher Looks promising, thanks for the link

Spinlock-only impl on native 😞

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.

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

@kpgalligan perhaps

arena

,

attr

and

mutex

fields should be private as they are implementation details 😀

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.

Looks better)