Re: Byte code compiling question

[Sam Roberts <vieuxtech@...>]

> Yes there is some other non related system stuff going on that made it
> easier to kill and create new tasks. I was aware that one possible solution

So, you have some kind of thread/task, that has it's own lua_State,
and you it is the
thread you are killing, causing the state to dissappear?

There are libraries around which will persist a lua
state into a file, but that is more likely to be slower, not faster.

I think a lua_State is the best representation of lua's state. You can
precompile the file,
saving a small amount of work. If you are certain the compilation
stage is what's slow,
try that.

If requireing modules is what is slow, you can preload them, might
save some time.

Still, if you are killing threads, keeping the state around is the
most obvious way of avoiding
the overhead of starting the state up again.

Not knowing much about your app, some other mechanisms for pausing a lua state
are:

- wrap the top-level function in a coroutine, and have it periodically
yield(), so the task's
C code gets control again, and can wait on some kind of mutex until
its allowed to continue.

- use the debug C hooks, you can cause them to call into your C code
periodically (at function
return, for example, or every few lua opcodes if necessary), check to
see if the state should
pause, and block on a mutex to stop lua until the state is allowed to continue.

- rewrite your top-level in lua... having it spin off tasks with code
in them, using lua as the
coordination language... probably out of scope!

Cheers,
Sam