SYNCing Event Firing from LUA Scripts

[SeaLyon]

Hi,

This is probably a stupid question, but I need some help with it. I have some LUA code that needs to use Voice:Speak to say some things and then trigger a girder event to start another action. I have several things that need to be said with different event triggers fired at the end of each specific saying. The problem I'm having is that girder appears to be pending the events until the script ends, firing all the ends at once. Here is some LUA code that demonstrates the problem (at least on my machine -- WinXP SP3). When this runs, it says the 2 sayings and THEN fires the event, instead of saying the first saying, firing the event, and then saying the second saying.


speech = {"",
"Say something.",
}

print ("START #5")
for _,v in ipairs(speech) do Voice:Speak(v, 0) end
print ("DONE #5")

-- <SEND ROBO_WAKEUP IR COMMAND>
gir.TriggerEvent("ROBO_39",18)

speech = {"",
"Say Something Else.",
}

print ("START #5b")
for _,v in ipairs(speech) do Voice:Speak(v, 0) end
print ("DONE #5b")

Is this the way girder should be processing this code? Does the script processor & event generator code run on the same thread? Is that what is causing the pending of the event? How can I get the event to fire in sync with what my script is doing since that's what I need? Also, I'm just using a girder event (#18), instead of creating my own user-defined event number, will that cause me any problems?

Thanks,
Chris

[Rob H]

As you've discovered if the script is running on the main thread then any events triggered will occur after the script has terminated.

You could run your script in its own thread to try to get around this.

And using a plain girder event should be fine.

[SeaLyon]

Trying to effectively design an application around the single-threaded nature of Girder certainly makes it more difficult than it should be. Are there any plans to at least provide some native multi-threaded support into Girder? I understand the issues (and don't believe them to be trivial), but the limits imposed by working in a purely single-threaded environment really reduce the things one could do with Girder. It would be nice if there were at least a few threads available for running scripts and if the event & scheduler systems could be running on their own threads too, so events could process in real-time instead of getting queued. I know its just a dream, but anyway ...

I've posted a couple times about using the current multi-treading support in Girder, but the major issue appears to be the thread-safe (or not!) aspects of Girder LUA and the libraries. I've asked about getting a list of exactly which commands/functions are thread-safe and some tips/techniques on making it work successfully, but have not seen anything. I've played with it a bit and have got some test code running, but not at the functional level I need. I can't spend my time experimenting to figure out what will & will not work, so unless you guys can provide a bit more guideance, I don't think moving to the current version of multi-threading will be successful for me now(given the limited time I have available).

So, given my specific application requirements running in the single-threaded environment, what would be the best way to structure my script(s) to get the functionality I need. The basic concept is that I need to have a voice script run, followed by generating some type of event to trigger an action, that action needs to complete, and then I need to follow the steps again (with a different voice script & action trigger). I guess I could break each voice/action step into a separate script and trigger them sequentially. Some of the actions will be carried out by the triggered event sending an IR command from Girder (no LUA code involved) but others will require a script to run and process the action. One issue with this will be fact that the action(s) will take variable time and I have to be sure the action completes before I trigger the next step. Another problem that I'm going to have to address is that I have other scripts that need to run on time boundries which now I'll need to manually schedule to ensure everything runs as needed. What needs to be done is fairly easy, trying to get it all setup to execute properly in the single-threaded environment greatly amplifies the challenges.

Appreciate any help.

Thanks,
Chris

[Ron]

Why don't you put the long lived lua scripts on a worker thread. This keeps the main Girder thread free and ready to process events?

Threads should be fine for the most part as long as you are careful with data access and mutexes, oh and stay away from luaCOM.