This implements #128: If it is possible to obtain a read-only snapshot of the database (i.e. when not batching updates from catching up), then SQLiteProcessors are run asynchronously on that snapshot. This allows them to run in the background without blocking the GSP, so it can continue attaching blocks.
Note that there can still be at most one instance of each processor running at any one time. If the previous run is not yet finished before the next would be started, it will be awaited synchronously. But this is still useful if the processor's runtime is potentially larger than the block time, but the processor is only run at an interval longer than its runtime. For instance, with this it is possible to run state hashing every Nth block in production GSPs (assuming N is large enough).
This implements #128: If it is possible to obtain a read-only snapshot of the database (i.e. when not batching updates from catching up), then
SQLiteProcessors are run asynchronously on that snapshot. This allows them to run in the background without blocking the GSP, so it can continue attaching blocks.Note that there can still be at most one instance of each processor running at any one time. If the previous run is not yet finished before the next would be started, it will be awaited synchronously. But this is still useful if the processor's runtime is potentially larger than the block time, but the processor is only run at an interval longer than its runtime. For instance, with this it is possible to run state hashing every
Nth block in production GSPs (assumingNis large enough).