-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
(Enhancement, not sure what's the impact of it, but I suspect it is significant for use-cases with single shard lua invocations)
Currently, an interpreter is acquired on the coordinator thread see ServerState::BorrowInterpreter()
But for single shard lua transactions we could actually use the interpreter running on the destination shard.
see Service::EvalInternal
and if (CanRunSingleShardMulti(sid, *params, *tx)) {
check.
We can not not do it now because of several reasons:
- the tx fiber should not block on anything as it will immediately create huge latency for all the operations scheduled on it.
- racing with other coordinator threads could lead to deadlocks where the tx A with lower id was blocked on the transaction B with higher id that acquired the interpreter but could not run because it waits for A to finish.
I believe the problem is that semaphore functionality of limiting number of interpreters is coupled with actually getting the interpreter. If we separate this and keep the limits at the coordinator level, we could get interpreters at shard level if needed
Idea: separate interpreter acquisition from the semaphore limits and use:
global vector<atomic_int> used_interpreter_count(pool->size())
- semaphores will still be enforced at the coordinator level.
- Coordinator will proceed only if used_interpreter_count is less than a limit.
- Once it proceeds it can acquire unconditionally an interpreter object in the thread it runs. So in case of
CanRunSingleShardMulti
, it will take it from the shard thread.