Best way to read on main actor?

[macdrevx]

I'm evaluating GRDB and one detail I wanted to clarify is the best way to read on the main actor. My understanding is that regardless of whether I use DatabaseQueue or DatabasePool, synchronous read from the main actor always involves waiting for another queue to perform the read. Is there any way to set things up so that there could be a read connection dedicated to the main actor?

[groue]

Hello@ @macdrevx,

No, there is no built-in way to perform a MainActor-isolated database access, or to dedicate a read connection to the main actor:

try dbQueue.read { db in
  // It is possible to have this closure run on the main thread,
  // but it is not MainActor-isolated.
}

Your app can define its own MainActor-enforcing connection, though:

@MainActor struct MainActorDatabaseReader {
    /// The MainActor-dedicated read-only connection
    private let dbQueue: DatabaseQueue

    init(dbQueue: DatabaseQueue) {
        self.dbQueue = dbQueue
    }
    
    func read<T>(_ value: (Database) throws -> T) throws -> T {
        try dbQueue.read(value)
    }
}

// MainActorDatabaseReader performs reads on the main actor.
// The compiler does not emit any warning or error for the following code:
@MainActor var myValue = "foobar"
@MainActor func readMyValue(_ reader: MainActorDatabaseReader) throws -> String {
    try reader.read { db in
        myValue // Fine, because this closure in MainActor-isolated
    }
}

Instantiate a MainActorDatabaseReader with a read-only DatabaseQueue instance, on the side of a "regular" writer connection. Make sure the database file is in the WAL mode, so that the MainActorDatabaseReader and the writer connection don't conflict and can be used concurrently. To do so, use a DatabasePool for writes, or a DatabaseQueue with WAL journalMode.

This technique is somewhat "exotic", but valid. GRDB aims at being able to address specific application needs, so I will not discourage you from doing so.

I'm not sure this is the best advice, though, because you did not tell what is the real problem you want to solve, and for which you think that "a read connection dedicated to the main actor" would be a solution (see the "XY problem").

Mind that if you want to observe database changes with ValueObservation, you'll need to give up MainActor isolation, and to make sure fetched values are Sendable (see ValueObservation and Swift Concurrency and GRDB in the GRDB 7 documentation).

[groue]

Dedicating a read-only connection for the main thread, as discussed above, is a way to avoid all risks.

If the library user has to perform some extra work in order to achieve a very common use case while "avoiding all risks", then maybe we can improve the library. It would not be a bad idea to have DatabasePool dedicate one reader to the main thread. This reader would never be used for background reads.

It's not because I never saturate the five default readers that nobody ever does.

I think this would be a reasonable feature request, that would match the expectation of most people, and maybe fix some UI freezes in some unfortunate apps.

[macdrevx]

It would not be a bad idea to have DatabasePool dedicate one reader to the main thread. This reader would never be used for background reads.

…

I think this would be a reasonable feature request…

I think this would be great! Please let me know if there's another place where I should submit this as a feature request 🙏

[groue]

No, you don't have to. The feature will probably ship in GRDB 7. This discussion was convincing.

I recommend that you use GRDB 7 beta right away. It is a better fit than GRDB 6 for the latest versions of Xcode and the Swift compiler. The final version is unlikely to introduce breaking changes.

You can even assume the feature will ship, and avoid MainActor-specific code. I'll let you know if I meet unexpected difficulties.

[groue]

Hi again @macdrevx. I had a closer look, and I discovered that I spoke too fast.

It is not possible to guarantee that all sync database accesses from the main thread are never blocked by background jobs.

Yes it can work for the read method and its siblings, but it is not for other kinds of sync accesses from the main thread, such as starting a ValueObservation with the immediate scheduling. There is no way for the library user to guess which kinds of sync accesses from the main thread would be guaranteed, and which ones would not. If DatabasePool would dedicate a connection to the main thread in specific scenarios only, its behavior could not be described in a simple way. Users would not build a mental model that is better than the current one (which is, I hope, "reads don't block unless readers are saturated").

So... we're back to the start: creating a read-only DatabaseQueue that your app dedicates to the main actor is probably the most explicit and best solution.

[groue]

Now I want to write a "Can I access the database from the main thread?" article in the doc :-)

[macdrevx]

creating a read-only DatabaseQueue that your app dedicates to the main actor is probably the most explicit and best solution

I wish there were a way to do this that avoided the hop to an internal serial queue altogether. E.g. while I could configure it to use the main queue, the internal use of DispatchQueue.sync would result in deadlock.

[macdrevx]

that avoided the hop to an internal serial queue altogether

My rationale is that just like the GRDB read queues in the database pool could conceivably be saturated by other reads, so could the thread pool that ultimately services the DatabaseQueue's underlying serial dispatch queue (e.g. other things in the same process also targeting the same global concurrent dispatch queue).

[groue]

Not if you only perform synchronous accesses. Quoting the documentation of DispatchQueue.sync:

As a performance optimization, this function executes blocks on the current thread whenever possible, with one exception: Blocks submitted to the main dispatch queue always run on the main thread