Holy shit Realm. This DB.... On Android it will crash if you access a reference to the db from a different thread than the one it was created from! 🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️

Why oh why can't they just have their own internals managing all the fucking thread they need? There's a reason they provide sync and async db access.

This basically means that my reference to a realm instance should always be tightly paired with the corresponding thread reference so that I can run my db queries on it.

👎

This is standard fare in a lot of C++ libraries. Use a thread safe messaging system.

https://academy.realm.io/posts/...

The question should be the other way around: Why do you want to do that?

It sounds (as I was curious) that you're approaching the problem from the wrong direction.

I'm not an expert, since I didn't knew realm before....

But what you described sounds like a locking nightmare you definitely want to avoid.

Take a break I guess?

@IntrusionCM not a locking nightmare, just pleasures of using Kotlin coroutines with the nightmare of Realm!

With Kotlin coroutines it's super easy to switch threads without the need for locks. It's all nicely handled by the coroutines lib. However, with Realm needing to be accessed on its own Android looper thread, you have to ensure that you switch to that thread before using your realm instance.

And passing around a realm instance is common for simple testing: poor man's dependency injection (constructor argument).

... a reference variable that crashes the program if you acces it by a different thread that the one which created it?

... that's SO WEIRD...
/s

@eeee it sounds for me wrong...

Switching threads doesn't require locks.

Yes.

Having mutable data shared between threads _must_ have locks.

That's non optional. Otherwise mayhem occurs.

You're complaining about the last fact imho.

I don't think a library can handle sharing mutable data between threads without specific context information, like eg Javas execution context.

Switching threads != Sharing data between threads

Why using Realm what's the use case if I may ask?

@gitpush that's because realm was acquired by mongo

@eeee aah I didn't know that, thanks for the info

@IntrusionCM what's wrong is that the underlying lib dependency of my realm reference on a particular thread leaks into my client code!

I cannot simply have all the threads where I need db access obtain their own realm reference directly! That violates various principles. I need to be able to test these realm usera, so I need to inject realm references and make assumptions about the thead this is all happening on 🤦‍♂️

Of course, it's also how we use it. But that part of the legacy in the system I work with 😬

And, btw, all my thread switching is necessary because I combine various data sources (db, network, memory) and UI updates close to each other. Thanks to realm I need to switch to precisely the right thread before accessing it, and then switch back.