Re: infinity loop / recursion

[William Ahern <william@...>]

On Mon, Aug 26, 2013 at 05:34:46AM -0400, Sean Conner wrote:
> It was thus said that the Great Philipp Kraus once stated:
> > Hello,
> > 
> > I'm using LUA for a simulation on a cluster system, so my user can define
> > their own scripts. In some cases there exists a infinite loop or infinity
> > recursion in the LUA code so the simulation does not stop anymore. My idea
> > is to create a maximum execution time (like PHP) with a watchdog (I don't
> > use a formal verification of the code e.g. wp-calculus). Each script has
> > got a defined function which is called by my C++ class, so I would like to
> > send the LUA script a "warning" that the max. execution time is reached,
> > but if the script does not stop, the C++ side should stop the script.
> > 
> > Can I / How can I stop a running script from C side? Do you think it is a
> > good idea to send a warning first, because the script does not use
> > threads, so IMHO the warning can not be handled by the script? I hope for
> > some ideas
> 
>   If you are using Unix, I can think of two ways that don't involve mucking
> with Lua.
> 
>   1). SIGALRM---set a handler for SIGALRM (signal() or sigaction()), then
> before running your script, trigger SIGALRM for the maximum amount of wall
> time you think the script needs (using either alarm() or setitimer()).  When
> the alarm goes off, your signal handler will get control.  
> 
>   2). Run the script in its own process, but set a CPU resource limit to the
> maximum amount of CPU time [1] the process can run.  The process may be able
> to catch SIGXCPU (CPU time exceeded) to know that it has exceeded its
> allowable amount of time, but I'm not sure what, exactly, will happen if the
> CPU time is exceeded (and thus, you have no more CPU to run).
> 
>   I'm not sure if it's a good idea to allow the script to check, because
> what can the script do?  

The problem with catching these signals is that you cannot simply resume the
process upon receipt (e.g. with a longjmp). Even excluding threads, the
application could've been in the middle of a malloc call when the signal
fired, with inconsistent state. Likewise with the Lua VM. The application
could easily crash; or worse, it crashes so rarely that it's never caught in
testing.

The only way to use these signals safely without exiting, or without
implementing your own libc, is to set and check a global flag.