Are there any examples out there of wrapping a cpp object and properly calling a cpp destructor when the kotlin object wrapping it is destroyed?

Kotlin can’t call cpp libraries without a C wrapper around the library.

Is there generally a way to tie memory lifetime from C to that of a Kotlin object?

Nope, they have to be manually destroyed. There's no sense of a destructor.

👍 thanks!

To be precise, there’s no user-controlled way to bind cleanup routine to Kotlin object. Control Kotlin object lifetime from C can be achieved by creating StableRef.

@olonho thanks! Specifically, we're trying figure out if there's a way to use a lock that's not a spin lock on Windows, but doing so requires knowing when we should cleanup the lock

object lifetime bound resources (such a Windows lock) doesn’t look like a great idea in general, use some scope bound resource control instead

@olonho here's an example where such a scope-bound resource isn't practical: https://github.com/touchlab/Stately/pull/6

Not sure why this PR manifests that scope-bound locks are insufficient. See how https://github.com/JetBrains/kotlin-native/blob/9d70ec0dbb21a4eea4db902218ed9a81940e0617/samples/videoplayer/src/videoPlayerMain/kotlin/Disposable.kt#L33 is used around videoplayer sample to solve similar problem.

@olonho i see. so not scope-bound necessarily (scope-bound to me makes me think of

memScoped {}

), but we should come up with a way to manually dispose of the lock/resource when we're done with it?

Yeah, let's call it logical scope, essentially predefined program execution fragment with clear boundaries

This does essentially force some resources back into the "free-it-yourself" style of mem management though, which is not great. It also feels a bit weird that you have to do this in the native world, unless you're running on iOS/macOS, where lock objects bridge for free

Nope, it’s not “free-it-yourself”, more like “think-over-program-behavior-yourself”. Binding resource mgmt to memory mgmt is pretty old anti-pattern of computer engineering, with well-known fundamental problems. With first-class functions, suspend functions and inline functions available in Kotlin one can think over composition rules so that there’s explicit resource consumption control.

👍 that's reasonable