Re: Lua embedded in a web browser

[Bennett Todd <bet@...>]

2000-04-21-16:57:14 Bennett Todd:
> The author of links has taken great care to avoid allowing any
> circumstance to cause links to hang. He raised the question, is
> there a way for C code to gracefully terminate the execution of a
> lua interpreter?

The author of links and I just exchanged another pair of notes on
the topic, where he clarified matters. Here's the exchange:


> Mikulas, the author of Links:
> Bennett Todd:
> > > Mikulas:
> > > Another question: is there a way to break an infinite loop? Is lua
> > > non-blocking? It wouldn't be good if links crashes just because
> > > user entered bad script.
> > 
> > Lua can be interrupted. If a user wrote an infinite loop, they'd
> > have to ^C the links that was running it, but then that's true of
> > any language I know of.
> 
> ^C won't work. Links does synchronous shutdown on ^C - it waits until all
> functions finish and control returns to select_loop(). kill -9 will do the
> job, but it's not good.
> 
> > I don't think that there's a way for C code,
> > say in an interrupt handler, to reach in and gracefully shut down a
> > Lua interpreter and restore it to a fresh-running state; on the
> > other hand, if we urgently want to have a watchdog timer to protect
> > against buggy user Lua scripts, the latest version supports explicit
> > contexts for multiple interpreters, so the interrupt handler may be
> > able to shut down the currently-running one and initialize a fresh
> > one, I'm not 100% sure.
> 
> Timer is bad idea - it can randomly kill script on heavily loaded system.
> 
> Lua must have the ability to save its state and return from interpreter
> after some time or number of instructions (or at some special
> instruction). Then links can do i/o handling and call lua interpreter
> again to continue at saved place. If the user writes infinite loop,
> terminal is not dead and the script could be killed in menu.
> 
> If lua can work this way, it could be in links. If the interpreter can't
> save state and return, it would be almost impossible to use lua. Not only
> because of breaking infinite loops. Links uses non-blocking calls to do
> all networking - if we want to be able to fetch file from lua script, the
> interpreter must return.

So, is there a way for the host program to place a limit on how
long Lua runs before it returns execution to the host, ideally with
the host able to allow the Lua program to resume for another time
slice after it's done its work for the moment?

-Bennett