3 ms·

How did the server side prevent infinite loops?

Rohansi 3y ago
Can't confirm but since it's running in a VM it could easily just time out and abort.
cryptonector 3y ago
Does it matter? You don't need infinite loops to eat up all available CPU and take forever to finish. Imagine nesting N loops that run from the smallest integer available to the largest integer available, so if you have 64-bit integers that's (2^64)^N, and N could be whatever you can fit in the code, which could be very large. You can prove that such a program terminates, but not in your lifetime for large enough N. And that's just the most trivial way I can think of to write a provably-terminating-but-not-practically program, and you can always implement faster growing functions and still terminate-just-not-really.
- 7373737373 3y ago
  I should have formulated my question differently: "How does the server side prevent computational resource exhaustion?", which includes the ability to preempt infinite loops. It matters and can be done, e.g. by using an instruction (and memory usage) counter and aborting/suspending after a certain number of instructions have been executed, or by using a timer as stated below.
  - classichasclass 3y ago
    Telescript apps ran with an execution budget (measured in "Teleclicks"). There was also a permissions system. Apps were signed to identify their origin and on whose behalf they were running.
    - 7373737373 3y ago
      Apparently this system was called "Permits", I just found a description here: https://web.archive.org/web/20210625004816/http://www.datarover.com/Telescript/Whitepapers/wp1/whitepaper-1.html https://web.archive.org/web/20210625004816/http://www.dataro... > Every Telescript place or agent has a permit that limits its capabilities in the electronic marketplace. Permits help protect the marketplace from malicious or misprogrammed agents by preventing their unbridled consumption of resources. Permits also protect the authorities under which agents operate by providing misprogrammed agents with a safety net. > Because agents move, their permits, like their credentials, are of special concern. An agent's permit is established when the agent is created programmatically, and it is renegotiated whenever the agent travels between regions. The destination region may deny the agent capabilities that it received at birth as long as the agent is in that region. (The region may not extend the agent's capabilities, however.) The region denies the agent entry unless it agrees to the restrictions the region imposes. When the agent eventually leaves the region, the restrictions are lifted (although those of another region are imposed). > Two kinds of capability are granted an agent by its permit. One kind is the right to use a certain Telescript instruction. An agent in the role of shopkeeper, for example, typically is denied the use of the go instruction. Another kind of capability is the right to use a particular Telescript resource, but only in a certain amount. An agent is granted, among other things, a maximum lifetime, measured in seconds (e.g., a 5-minute agent); a maximum size, measured in bytes (e.g., a 1K agent); and a maximum overall expenditure of resources, the agent's allowance, measured in teleclicks (e.g., a 50¢agent). (In theory, the teleclick is an abstract unit of measurement. In practice, however, an "exchange rate" between teleclicks and money is established.) > The Telescript engine that supports an agent constantly monitors its resource consumption. If the agent exceeds any of its quantitative limits, the engine destroys the agent unceremoniously. No grace period is extended. The agent has, as the saying goes, "no place to run, no place to hide." > An agent's permit plays an important role in the electronic marketplace by enabling the agent's authority to constrain the agent's activities a priori.

Can't confirm but since it's running in a VM it could easily just time out and abort.

Does it matter? You don't need infinite loops to eat up all available CPU and take forever to finish. Imagine nesting N loops that run from the smallest integer available to the largest integer available, so if you have 64-bit integers that's (2^64)^N, and N could be whatever you can fit in the code, which could be very large. You can prove that such a program terminates, but not in your lifetime for large enough N. And that's just the most trivial way I can think of to write a provably-terminating-but-not-practically program, and you can always implement faster growing functions and still terminate-just-not-really.

7373737373 3y ago
I should have formulated my question differently: "How does the server side prevent computational resource exhaustion?", which includes the ability to preempt infinite loops. It matters and can be done, e.g. by using an instruction (and memory usage) counter and aborting/suspending after a certain number of instructions have been executed, or by using a timer as stated below.
- classichasclass 3y ago
  Telescript apps ran with an execution budget (measured in "Teleclicks"). There was also a permissions system. Apps were signed to identify their origin and on whose behalf they were running.
  - 7373737373 3y ago
    Apparently this system was called "Permits", I just found a description here: https://web.archive.org/web/20210625004816/http://www.datarover.com/Telescript/Whitepapers/wp1/whitepaper-1.html https://web.archive.org/web/20210625004816/http://www.dataro... > Every Telescript place or agent has a permit that limits its capabilities in the electronic marketplace. Permits help protect the marketplace from malicious or misprogrammed agents by preventing their unbridled consumption of resources. Permits also protect the authorities under which agents operate by providing misprogrammed agents with a safety net. > Because agents move, their permits, like their credentials, are of special concern. An agent's permit is established when the agent is created programmatically, and it is renegotiated whenever the agent travels between regions. The destination region may deny the agent capabilities that it received at birth as long as the agent is in that region. (The region may not extend the agent's capabilities, however.) The region denies the agent entry unless it agrees to the restrictions the region imposes. When the agent eventually leaves the region, the restrictions are lifted (although those of another region are imposed). > Two kinds of capability are granted an agent by its permit. One kind is the right to use a certain Telescript instruction. An agent in the role of shopkeeper, for example, typically is denied the use of the go instruction. Another kind of capability is the right to use a particular Telescript resource, but only in a certain amount. An agent is granted, among other things, a maximum lifetime, measured in seconds (e.g., a 5-minute agent); a maximum size, measured in bytes (e.g., a 1K agent); and a maximum overall expenditure of resources, the agent's allowance, measured in teleclicks (e.g., a 50¢agent). (In theory, the teleclick is an abstract unit of measurement. In practice, however, an "exchange rate" between teleclicks and money is established.) > The Telescript engine that supports an agent constantly monitors its resource consumption. If the agent exceeds any of its quantitative limits, the engine destroys the agent unceremoniously. No grace period is extended. The agent has, as the saying goes, "no place to run, no place to hide." > An agent's permit plays an important role in the electronic marketplace by enabling the agent's authority to constrain the agent's activities a priori.