Your entire event loop could be called within a hook that ran every x instructions. This should offer good response time and is trivial to implement. I don't see any problem with that approach, and I don't think there is any other way to preempt the VM without help from the OS. The drawback would be having your event loop run so often, but this is unavoidable without interrupts of some kind.
By the way, I've heard Lua has already been ported to Palm OS, unless you mean Lua5.1.
________________________________
From: lua-bounces@bazar2.conectiva.com.br on behalf of Gerhard Sittig
Sent: Thu 12/29/2005 6:23 PM
To: Lua list
Subject: Re: running the Lua VM "in time slices"
On Thu, Dec 29, 2005 at 19:47 -0200, Luiz Henrique de Figueiredo wrote:
This may sound weird, but can the Lua VM be run in "slices", doing part
of its current job, returning control to its caller and resuming the
suspended job in a subsequent call?
Yes, use coroutines.
Oh, I'm sorry. Guess I didn't explain myself very well. :-/ The
problem is not to run Lua code (self produced or under my control) in
slices or in parallel to each other.
The situation is this: A main application written in C embeds the Lua
VM and runs user supplied scripts and modules in it. The C code needs
to run the Lua VM (with the regular lua_open(), luaL_loadfile(),
lua_pcall(), lua_close() sequence). While I have absolutely no
influence on how the lua code is designed and written or how well it
would behave. But to handle events in the C application's main event
loop, control (CPU time) needs to be transferred from the Lua VM back to
the main application which called lua_pcall() to execute the Lua scripts
the user provided. Optimally by returning, not by means of a callback.
The best thing would be if the initial lua_pcall() issued from the C
application to run the Lua code could be given a constraint "and spend
at maximum this much time and then return (prepared to resume later)".
Another approach could be to use debug hooks to run a small event loop
at regularly scheduled intervals. That's what I tried to sketch in the
opening message of the thread.
It's a pity that neither background jobs nor threading are available.
While it's essential to process events for the UI (including stdin and
stdout/stderr) and even for the base functions like file I/O. (For the
curious among us: I try to port Lua to PalmOS, although not too
seriously -- it's a low priority toy project and I'm still evaluating if
this can be done and how it could be achieved, haven't started any
coding yet.)
Or am I misunderstanding your reply and you suggest to use coroutines
(in the C language part) between the main application and the Lua VM?
Like switching from the app to Lua when there are no events left to
handle and switching back from Lua to the app when a debug hook would be
due? Haven't considered this approach yet but it's interesting, too. :)
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
