dbExecute from scheduled context still "freezes?" despite documentation

[mcoffin]

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 :)

[mcoffin]

@dedmen Not trying to be too much of a bother, but after #30 is merged (although we obv have it locally so this isn't a blocker), this is one of the few remaining items blocking our switch, so any information you can provide on that system (the callstack_item that dbExecute uses to wait, and what might be wrong with it causing it to appear to "freeze" the game), would be greatly appreciated

[TommKirkk]

@dedmen any update on this pretty please ? :)

[dedmen]

Can you give me some simple repro steps for freeze?
I checked my code when I saw you create the ticket and found nothing wrong.

[TommKirkk]

Apologies I should've replied properly on the #30 merge and not this one. @mcoffin I presume will have some repro steps for this specific issue