[DGD] Kernel Library wiztool - out of ticks in cmd_code

[Neil McBride]

Hi all,

I've just realised through a bug in my object manager that if I  
execute a 'code' command that causes an out of ticks error ("code  
while(!a); return a" will do it), the object that the command created  
as /usr/owner/_code does not get destroyed.  Although it did help me  
find and fix a bug in my object manager, I was wondering why the code  
isn't executed differently to catch the out of ticks error and came  
across the following post from a few years back via Noah Gibbs'  
website where Dworkin said: -

> When error recovery is essential, there are two things you can do.
>
> 1. You can make sure that something happens using rlimits:
>
>     rlimits (0; -1) {
> 	catch {
> 	    call_limited("foo");
> 	} : {
> 	    /*
> 	     * this MUST complete to fully recover from an error
> 	     */
> 	    bar();
> 	}
>   }
>
>    There are several problems with this approach.  First, when using
>    the kernel library, only System objects can use rlimits (...; -1).
>    Second, an infinite loop in bar() will hang your mud forever.
>    Third, even though foo() is called with limits appropriate for the
>    current object, those limits are reset for the call, thanks to the
>    enclosing rlimits (..; -1).  Fourth, the ticks spent in bar() will
>    not be accounted for using the kernel library's resource management
>    system.

Is there any reason this approach would not be appropriate in the  
kernel's wiztool object to ensure the object gets destroyed following  
an out of ticks error?  It's a System object, I would expect an  
infinite loop when destructing the object to be unlikely and the limit  
resetting and unaccounted destruction don't seem like an issue.

Thanks,

Neil.