Concurrently executing functions (scripting)

[Budskii]

Hello,

I have recently stumbled across this projecting recently and have found it very intriguing. I would like to use runtime compiled C++ as a scripting language, the performance of native C++ code for scripts would be amazing. I've seen the source code and it seems fairly easy to implement but I'm stumped on one issue. With the current scripting language I use, I have a separate thread which executes all the scripts in parallel. It gives each script 20ms of execution time then pauses that script and runs next one and so on. How could this be achieved on RC++? It could easily be done by creating a seperate thread for each script, but that would be too many threads and ideally, I would like only one worker thread executing all of the scripts. Is there any way I could limit execution time for script->Update() function? With the current scripting language I use (angelscript) you can also pause execution of a script anytime and resume it from where you left off, this is really useful when scripting hasn't finished executing in the 20ms time. I imagine, this would be extremely difficult to implement but If I was able to limit execution of a function then that would be good enough for me

Regards,

Bud

[Doug Binks]

Hi Bud,

RCC++ allows C++ code to be compiled and swapped at runtime, so the resulting code is standard compiled C++. Thus the question you have is a general C++ one - can you limit the execution time of a C++ function? This is equivalent to writing a preemptive kernel in user mode (see http://www.eran.io/implementing-a-preemptive-kernel-within-a-single-windows-thread/ for an example, though this code will only work for 32bit Windows programs).

As you note you could do this with threads. You don't need one thread per script however, you just need one thread per script which takes more than 20ms to run.

An alternative is a cooperative approach where your scripts call a function that runs other scripts if the time taken is too long. This could be done with fibers or simply by calling the next scripts update.

However I'd simply avoid this, and ask programmers to write their code so updates don't take too long in a single update - this is the standard approach for C++ games developers.

[Budskii]

Hello,

Thanks for the reply, as I thought, this would be too difficult to implement and I do need 64bit support so preemptive kernel in not an option. I've thought more about this, and actually I think the 20ms per script shouldn't even be a problem anymore since code execution of scripts shouldn't even take a ms. The only exception to that would be the sleep calls in scripts would need to be implemented differently but it should all be fine. I think script loading and updating can all be done in the main thread but for scripts that need to use sleep calls, I will create one worker thread with a queue implementation which handles all of this. Scripts could then use it like so:

void do_stuff()

{

       //this will run in a seperate worker thread;

      

       ...do stuff here

       Sleep(500);

       .. etc etc

}

void Update()

{

       static float lastRan = 0;

       float timeNow = timeGetTime();

       if(timeNow - lastRan >= 5000) //every 5 seconds

       {

              ExecThread(do_stuff);

              lastRan = timeNow;

       }

}

[Doug Binks]

Rather than use sleep calls I would either create an timed event system (push a callback onto a time ordered event queue with a specific time to run), or simply check the time and return if it's not ready to do work - for a small number of scripts the later would be fairly simple and work well.

--
You received this message because you are subscribed to the Google Groups "Runtime-Compiled C++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to runtimecompiledcpl...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy]

You should also consider cooperative coroutines, also sometimes called fibers, or microthreads. They are a much lighter weight construct that is great for compartmentalizing scripting. The downside is that it's not meant for performance, in that it typically doesn't utilize multiple threads. These are the basis of lua coroutines, unity monobehaviors, game monkey script "threads", etc