RFC: Catching timeouts

[Luke-Jr]

I'm thinking it would be nice to be able to catch timeouts (both seconds and
ticks). The way I envision it:

try
$foo();
except e (ANY, 1, 100)
$command_utils:suspend_if_needed(0);
/* error handling */
endtry

In this case, the $foo() verb has 1 second and 100 ticks LESS total before it
times out, at which point control will return to the exception (which also
handles any error, in this example) which immediately suspends (if needed)
before handling the error or timeout.

This allows webservers (and similar things) to do more graceful cleanup of the
request.

Possible problem:
- Giving non-wizard tasks the ability to manipulate the maximum time/ticks of
the verbs they call could lead to security issues (think of setting it so a
money-transfer verb times out right after it deducts from PlayerA's balance,
but before it adds to PlayerB's...)

Thoughts/suggestions?

[Josh Benner]

Ooh, interesting idea.

I wonder if it might be easier to have a builtin along the line of
set_timeout(...) that initiates a VM state that will track the clock
and throw the exception. I'm not entirely sure which makes more sense
internally, but I'd want something more expressive. Alternately,
perhaps:

except e (ANY) until (1, 100)

or

except e (ANY)
...
timeout (1, 100)
...

[Luke-Jr]

On Friday, December 02, 2011 11:53:43 AM Matthew Walker wrote:

> On Thu, December 1, 2011 9:01 pm, Luke-Jr wrote:
> > Possible problem:
> > - Giving non-wizard tasks the ability to manipulate the maximum
> > time/ticks of
> >
> > the verbs they call could lead to security issues (think of setting it
> > so a money-transfer verb times out right after it deducts from
> > PlayerA's balance, but before it adds to PlayerB's...)
>

> What about instead of reducing the available ticks to the called code, the
> exception handling code is /given/ time to complete its work.

What would stop someone from chaining them to get effectively infinite
ticks/seconds?

How about a "when a timeout happens, your verb WILL suspend before the handler
executes" rule? ;)

[Todd Sundsted]

Improvement here would be ideal! The current implementation is
simple, and works well, except when it doesn't. I'd like the
exhaustion of ticks/seconds to raise a catchable error (perhaps only
catchable by verbs running with wiz-perms, or using a mechanism like
you described). I'd like a more foolproof means of ensuring tasks
have sufficient ticks/seconds to run to completion -- it's almost
impossible to write complex code that is guaranteed never to run out
of ticks/seconds. And I'd like a means of marking sections of code
which must either succeed or fail atomically. That's my wish list :-)

Todd

On Dec 1, 11:01 pm, "Luke-Jr" <l...@dashjr.org> wrote: