dbExecute from scheduled context still "freezes?" despite documentation #31

According to the documentation, dbExecute, when called from a scheduled context, should

[suspend] the script like a sleep/waitUntil would do, and continues once result is ready

however, when running a non-headless server (i.e. eden play in multiplayer or "Host Server" from the ArmA III client), each call to dbExecute still appears to "freeze" all animations (and therefore likely the game). I imagine that this is still the case when running a dedicated server, but that the freeze is not as apparent as when visible in animation/etc on a client with an interface, though I cannot yet confirm that, as I have not investigated or implemented the tooling that would be required to prove it so.

Is there any information @dedmen or others could provide as to what the intended consequence of d1 = n is in callstack_item::next(...) for all relevant values of n? Short of using a debugger to attempt to reverse-engineer a waitUntil call, I don't currently know of a fantastic path to see what is occurring during the execution of the callstack_item.

It seems that setting d1 = 3 in callstack_item::next(...) is intended to indicate to the scheduler that the fiber (for lack of a better term) should yield after each that call to next(...), meaning that I would not see the animation and game "freeze" that I do right now. I have properly verified that the context canSuspend in SQF, and that the is_scheduled member of the vm_context is true on the intercept side.

To me, it seems one of two things are likely true:

1. There is a misuse of callstack_item's next(....) API that causes the freeze
2. There is a fight over a shared resource mutex between nigh all game threads, and the code awaiting the fulfillment of the future from the DBGameDataAsyncResult.

Thanks for reading, and I appreciate any tips/documentation that can be offered in our pursuit of an implementation of this that suits our needs :)