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:
- There is a misuse of
callstack_item's next(....) API that causes the freeze
- 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 :)
According to the documentation,
dbExecute, when called from a scheduled context, shouldhowever, when running a non-headless server (i.e. eden play in multiplayer or "Host Server" from the ArmA III client), each call to
dbExecutestill 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 = nis incallstack_item::next(...)for all relevant values ofn? Short of using a debugger to attempt to reverse-engineer awaitUntilcall, I don't currently know of a fantastic path to see what is occurring during the execution of thecallstack_item.It seems that setting
d1 = 3incallstack_item::next(...)is intended to indicate to the scheduler that the fiber (for lack of a better term) shouldyieldafter each that call tonext(...), meaning that I would not see the animation and game "freeze" that I do right now. I have properly verified that the contextcanSuspendin SQF, and that theis_scheduledmember of the vm_context istrueon the intercept side.To me, it seems one of two things are likely true:
callstack_item'snext(....)API that causes the freezefuturefrom theDBGameDataAsyncResult.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 :)