Re: Timing out LUA programs

[Sean Middleditch <elanthis@...>]

On Tue, 2002-06-18 at 14:27, Björn De Meyer wrote:
> Sean Middleditch wrote:
> > 
> > Again, with Lua's co-threads support, it should be very easy (I would
> > imagine - haven't look at internals in a while) to make a
> > pre-emptive-ish threading system.  Simply do something akin to forced
> > yields, add in Lua mutex/semaphore data types, etc.  The main engine
> > would look at all available threads, and run each for X amount of time
> > or for X byte-code operations, then return to calling C code.  This way,
> > an application could launch Lua threads, and then have a
> > "lua_run_threads" call in the main update/event loop.
> 
> Well, that could be helpful. Such a Lua would still block when calling 
> the C functions, though. Contrary to what I said before, there is no 
> truly correct and portable way to do coroutines in plain ANSI C. 
> You need system-dependent extensions, and then we're even farther from
> home,
> so to speak.

Yes, there is a problem with threading inside of C functions.  That has
to be handled generally with a less than optimal way - i.e., requiring C
functions to be coded specially for threading (allow them to return with
a status code, then recalled with the status code to let them know where
they broke off, and the function would have to check for a "context
switch" state after every Lua call that could trigger such a switch -
would this not be similar to a C function calling a co-thread that then
yields tho?), or disable threading when there is a C function on the Lua
call stack.

> 
> On the other hand, it might be the question why you would use a separate 
> "microthread" for each and every agent in an AI system. Simply looping 
> over all agents in a big (timed) loop, or using some kind
> of message passing and/or callbacks can be just as efficient,
> not to mention a lot simpler, as you have no pains with mutexes and
> semaphores.

If I have 200 active agents, for example, even a very small AI script
will eat up a few milliseconds - that equates to about 400 milliseconds
per frame just for AI, and that is with a very simple AI.  With a
pre-emptive system, larger AI tasks (ones that have a lot of logic or
math in them) will be auto-matically broken up.  Plus, a good script
schedular would be able to decide to only call a limited number of
threads per lua_run_threads() call, so one frame 20 agents are updated,
next frame the next 20 agents, etc.

One wouldn't want to just replace cooperative threading tho (I finally
found a use for stuff ^,^ ) since it good for animation scripting:

move_to (1.5, 2.0, 4.5)
face_direction (NORTH)
target = nearest_enemy ()

... etc.

The long and short of it is that callbacks are not sufficient for
immersive behaviour scripting.  Plus, any scripting language used needs
to be capable of intelligently scaling down the amount of processing it
does per frame, by breaking up tasks or multi-frame scheduling.

This is yet another reason so many game authors keep writing their own
scripting language - no complete freely available language I know of
handles this intelligently.  Especially when you are writing a game that
customers are allowed to modify/script, where you have non-professionals
who don't know how to optimize efficiently.

> 
> -- 
> "No one knows true heroes, for they speak not of their greatness." -- 
> Daniel Remar.
> Björn De Meyer 
> bjorn.demeyer@pandora.be