Short: MAX_TIME is a bad idea - here is why.
From: Lars and Macbeth
Date: 990324
Type: Feature
State: Acknowledged.

(Translation of an online discussion, edited for content)

Summary:
  - it must at least be possible to temporarily turn off the real-time
    limit (see f-981229-11). This also involves something analog to
    CATCH_RESERVED_COST.
  - an alternative to MAX_TIME would be weighting the eval ticks to
    the complexity of the operation.
  - a driver-rewrite would yield an even better solution.

Note: MAX_TIME was axed in 3.2-dev.69 due to implementation problems.
The basic idea is worth considering, but an actual implementation needs
more thought.


Me: What's the problem with the hard time limit on evaluations? Amylaar
    said that it could cause security problems, but I can't imagine
    what you could do with it.

Macbeth: He's right. Even though it's quite tricky to create a useful
    exploit, you can leave security-sensitive data in inconsistent state.

Me: Like with the soft limit we already have for eval ticks?

Macbeth: Yup, but there could build in checks into the mudlib. I can't
    do that with hard time limits.

Me: Why? I seem to remember that I also made an efun returning the
    remaining time.

Macbeth: For once I'd have to adapt code in a thousand places, and second
    it is only of limited use. Limited because the real-time behaviour
    of LPC is not very predictable (to put it mildly).
    Just imagine a chain reaction of deallocations...

Macbeth: I don't like it at all from the point of security issues, and
    also for other reasons. And it doesn't really help against an endless
    loop in save_object(), for example.

Me: I understand. Nice catch22 - without it every wizard can freeze the
    mud with a simple loop.

Macbeth: I can do that whatever you do. ed for example offers thousands
    of possibilities.

Me: What 'other reasons' do you have?

Macbeth: That it isn't predictable, and that perfectly clean code can
    produce inconsistent data. Take /basic/database.c here: if one
    item becomes inconsistent, you lose the whole file.

Me: Damn. I thought a limit of 1 minute or more would be safe, but of
    course if the mud blocks on a file operation...

Macbeth: Exactly. For this you can only look at the time spent in the
    process, else the mud will crash over simple NFS problems. But then
    the limit can easily be circumvented with file operations.

Macbeth: Furthermore it's a hack. (It would be different if you would
    also give me a possibility for an atomar execution of extensive LPC
    operations, but just a function to measure the remaining time is
    not enough).

Me: Like the request to execute certain pieces of code without regard
    to the eval-tick limit?

Macbeth: Yes, but [this one would be] less critical because endless loops
    would still run into the other limit.

Macbeth: There is a _very_ elegant solution, but it involve an extensive
    rework of the driver.

Me: Tell me. Even if I can't implement it, I can at least collect ideas
    for people with more time.

Macbeth: A primitive  'atomic { ... }'. If an error occurs in the inside,
    the driver is reset to the state at the start of the primitive,
    including eval-cost errors. You know what that means.

Me: If 'state of the driver' includes the state of all objects/mappings/-
    arrays/... - Ugh.

Macbeth: Precisely. On occurance of an error, everthing is undone.

Me: No problem. I just have to find somebody who pays me for this kind
    of work ;-)

From afar, Macbeth grins at you.