ESOUI - Wait for a function to end before continue

ESOUI (https://www.esoui.com/forums/index.php)

- Lua/XML Help (https://www.esoui.com/forums/forumdisplay.php?f=175)

- - Wait for a function to end before continue (https://www.esoui.com/forums/showthread.php?t=2213)

Wait for a function to end before continue

Hi

I have a function that is triggered by an event and within this function there are several sub-functions that are called.
The first sub-functions makes use of some "zo_callLater" and the end of this sub-function is reached earlier than all the "zo_callLater" are ended (they might take 2-3 seconds). So the second sub-function is already called although not all "zo_callLater" from the first sub-function have ended, which causes some problems in the addon.

Currently I deal with this situation in the following way:
The first sub-function returns "true" as soon as all "zo_callLater" calls are completed. I then check this value in a loop if it is "true" and only in that case allow the main function to call the second sub-function.

Lua Code:

local mainFunction()
    -- call the first sub-function that contains some 'zo_callLater'
    local isCompleted = callFirstSubFunction()
 
    while (isCompleted == nil) do
        -- do nothing; wait
    end
 
    -- call the second sub-function
    callAnotherSubFunction()
end

It basically works, but I am not sure how bad (performance-wise) this solution is.
I don't see any game-freezing effects like a regular endless-loop would cause, but I thought there might be a better solution for this?

Klingo

This is when I typically use the update tic. Update tic callbacks are "asynchronous". Your wait loop is "synchronous". It technically causes more churn, and locks the process until that loop ends.

Code:

local firstRunCalled = false

local firstRunComplete = false

local callFirst = function(...)

    -- do whatever has to happen first

    firstRunComplete = true

end

local callSecond = function()

    -- do your second thing here

end

local mainFunction = function(eventType,...)

    if firstRunCalled and eventType ~= nil then return end 

        -- eventType having a value means it came from the event handler, not our update tic. 

        -- Since we're already running, skip it until last pass completes

    if not firstRunCalled and eventType == nil then return end

        -- standard update tic but we're not processing

        -- so kick us out

    if not firstRunCalled then

        firstRunCalled = true

        firstRunComplete = false

        callFirst( ... )

    end

    if not firstRunComplete then return end

        -- kick us out if it isn't complete yet

    firstRunCalled = false

    callSecond()

end

EVENT_MANAGER:RegisterForUpdate("myaddon_mainfunction_updatetic", 100, mainFunction)

EVENT_MANAGER:RegisterForEvent( "myaddon_mainfunction_eventwatch", EVENT_WHATEVER, mainFunction)

Something like that, perhaps. Sorry, this is off the top of my head. Basically hook your mainFunction into both the event, and the update callback.

Klingo, the snippet you posted looks ripped out of context, and unlike what you described. isCompleted is assigned exactly once, never changes value, so that loop is either done immediately, or runs forever :)

I'd slightly modify Wykkyd's method. In your event handler, check if an update func is registered - if yes, return immediately (or note that the whole process needs restarting; depends on what your addon does with the event), otherwise do required preparations and register for update. In update you can check elapsed time, call other functions when they're due, and after the last one is finished, unregister (or restart if there was another event).

Quote:

Originally Posted by Klingo (Post 12008)

Lua Code:

local mainFunction()
    -- call the first sub-function that contains some 'zo_callLater'
    local isCompleted = callFirstSubFunction()
 
    while (isCompleted == nil) do
        -- do nothing; wait
    end
 
    -- call the second sub-function
    callAnotherSubFunction()
end

That's called busy waiting and is probably the worst-performance for waiting on something. You eat resources checking constantly, even though you don't need to.

The solution Wykkyd provided basically tones down how often you check.

If you have access to all functions you could also do something like this, where the check is at the end of each sub-call. This would keep the times you check for updates to a minimum.

Lua Code:

local foo_done = false
local bar_done = false
 
function checkEnd()
    if foo_done and bar_done then
        --call end stuff
    end
end
 
function foo()
    --Do stuff
    foo_done = true
    checkEnd()
end
 
function bar()
    --Do other stuff
    bar_done = true
    checkEnd()
end
 
function mainFunction()
    foo_done = false
    bar_done = false
    --asynchronous calls
    zo_callLater(foo, 100)
    zo_callLater(bar, 100)
end

There are two even better ways to accomplish this that do not use any sort of a timer to poll to see if it's ready.

#1 - Have the script you assign to the zo_callLater call actually call the next function when it's finished.

Lua Code:

local function callAnotherSubFunction()
     --do other stuff after zo_callLater is finished
end
 
local function callFirstSubFunction()
     --do stuff
     zo_callLater(100, function()
               --do something later
               callAnotherSubFunction()
          end)
end
 
local function mainFunction()
    callFirstSubFunction()
end

#2 - Use callbacks. Register for a custom callback (a custom event) which is fired by the zo_callLater call, and have your callback handler be the second function.

Lua Code:

local function callFirstSubFunction()
     --do stuff
     zo_callLater(100, function()
               --do something later
               CALLBACK_MANAGER:FireCallback("zo_callLaterFinished")
          end)
end
 
local function callAnotherSubFunction()
     --do other stuff after zo_callLater is finished
end
 
local function mainFunction()
    callFirstSubFunction()
end
 
CALLBACK_MANAGER:RegisterCallback("zo_callLaterFinished", callAnotherSubFunction)

Quote:

Originally Posted by Seerah (Post 12020)

There are two even better ways to accomplish this that do not use any sort of a timer to poll to see if it's ready.

I'd go with callbacks for this. Its more efficient.

Quote:

Originally Posted by Fyrakin (Post 12067)

I'd go with callbacks for this. Its more efficient.

Oops - yes. I forgot to put that this would be my preference.

Thanks a lot for all the feedback, it's much appreciated!
The solution with callbacks definitely seems to be the best way to go on with.