24: Sponsored Operations and Multitasking

1. Sponsored Operations
   1. When a process calls an unsponsored operation (which all ops are unless declared otherwise) on an object, the process (the requester) is the sponsor of that operation.
      1. The operation runs under the authority and permit of its sponsor so it won't use resources and perform actions that are beyond permissions for the sponsor.
   2. When one process calls an operation on a second process, the requester (first process) is by default the sponsor, so the operation runs under the authority and permit of the first process, even though it belongs to the second process, which has its own authority and permit.
   3. A process may want some of its operations to run under its own authority and permits even when called by other processes. If so, it declares those operations to be sponsored operations. (Think of them as "self-sponsored" operations.)
      1. An operation is declared to be a sponsored operation using the "sponsored" keyword
      2. Operations so declared execute under the authority and permits of their responder, not under the authority and permits of the requester with one exception:
         1. The age capability is the most constrictive setting found in the responder's permits and the requester's permits. This ensures that a sponsored operation must take no longer than the time available to the requester or the responder.
      3. Operations not declared using this keyword execute under the authority and permits of the requester.
   4. Some operations in a process must be declared sponsored operations because they're called by the engine, and must execute under the authority and permit of the process and not of the engine. Those operations are:
      1. "live", called when a process is first constructed
      2. "entering", called when a process first enters a place (on construction or later)
      3. "meeting", called when an agent is requested for a meeting
   5. Operations that are not part of a process may not be declared a sponsored operation, because the object has no authority or permit.
2. The engine starts a thread each time it calls a sponsored operation on a process.
   1. A thread is a stream of execution; many threads can execute simultaneously in the multitasking environment of the Telescript engine.
   2. A process may have more than one thread executing at once, so it can, in theory, be simultaneously living (one thread) and performing sponsored operations for other processes (a thread for each operation).
   3. A thread is a FILO stack of frames.
      1. Each frame supports a single method.
         1. A frame contains the variables and a stack of arguments used in the method.
      2. A frame is added to the thread each time an operation is called (unless, of course, the operation is a sponsored operation called by the engine).
      3. A frame is popped from the thread each time an operation is finished.
      4. Only the frame at the top of the thread is executed. Its method is called the current method. The current method works with the variables and arguments in the frame.
   4. When an operation is finished, its thread is destroyed.
   5. The engine can support concurrent threads through multitasking so each thread executes independently of another.
3. Priority
   1. Each process has a permit-granted priority of -20 (low) to 20 (high). (0 is the normal priority.) A process's threads run at that priority.
   2. The engine spends equal execution time on threads of equal threads of the highest priority (unless a process is blocked, in which case its thread doesn't execute).
   3. Lower-priority threads must wait until higher-priority threads finish execution; the lower-priority threads then take their turn as the highest-priority threads--until a higher-priority thread appears, at which point they're suspended once again.

Generated by the sweat of Mike Boom's brow.