Depending on how you open your database (i.e.: with .shm and .wal concurrency) this might be less of a problem now? Otherwise, an option might be to add your own abstraction (i.e: JBReadWriteDatabaseQueue
) which internally has both a read and a write arrays of blocks (or their own queues). It could then expose methods like readInDatabase:
and writeInDatabase
which might pass on the block directly to the fmdb queue if nothing is running, or store them if it is running. On completion of the current fmdb block, this class could preferentially pick from the read block arrays if there were entries there.
This does then get further into fun cases like write starvation if the read array never clears, but hey, such is life in concurrency eh?