An issue like this would have far reaching affects and needs to be addressed. I am just searching for an actual bug here - one that can be duplicated so I know what not to do in our own code.
Once that’s established, actually answering the question would be possible.
So I read through all of those “deadlock” links. The issue is that “deadlock” describes different things to different people, so many of the bug reports were not on topic… for this topic.
What I am seeing over and over is this:
@tkafka we do release the file lock on the Realm file. You need to make sure the Realm is not in use otherwise you app will continue to hold the lock. If you want to release the file lock after a write consider the following approach:
autoreleasepool { let realm = try! Realm(...) try! realm.write { ... } } // realm will be released along with file lock after this block
and
Hi @alexeichhorn,
That’s expected. You should not run blocking code in.initialand that’s exactly whatwritedoes.
You may asynchronously dispatch calls forupdateDog/updateNames.
and
Thread 2 (a background thread) is holding the write lock and attempting to synchronously dispatch work to the main thread, but the main thread is already waiting for the write lock and so things deadlock.
and then other threads that have ‘deadlock’’ issues caused by infinite loops or setting up objects that perform recursive initialization.
We’ve tried multiple gyrations to duplicate the issue and even with a massive file 2Gb worth of data, we simply can’t make it happen so I don’t know what the answer would be. We’ve never lost any data with Realm, regardless of the file structure or location. Is this maybe something related to the OS?
Do you have a minimal, reproducible example of how to make this bug appear?