Compm. lang. Vol. 12, No. 2, pp. 109-121, 1987 0096-0551/87 $3.00+0.00 Printed in Great Britain. All rights reserved Copyright ,~ 1987 Pergamon Journals Ltd ABSTRACTING TIMED PREEMPTION WITH ENGINES* CI-mls'ropi-mR T. HAYNESand DANIEL P. FRIEDMAN Computer Science Department, Indiana University, Lindley Hall 101, Bloomington, IN 47405, U.S.A. (Received 18 July 1986; revision received 19 November 1986) Almtrtct--The need for a programming language abstraction for timed preemption is argued, and several possibilities for such an abstraction are presented. One, called engines, is adopted. Engines are an abstraction of bounded computation, not a process abstraction in the usual sense. However, in conjuction with first class continuations, engines allow a language to be extended with time-sharing implementations for a variety of process abstraction facilities. We present a direct implementation of hiaton streams. Engine nesting refers to the initiation of an engine computation by an already running engine. We consider the need for engine nesting and show how it may be accomplished in a manner that charges a parent engine for the computation of its offspring. We conclude by discussing the importance of simple and general abstractions such as engines. Engines First class objects Preemption Continuations Hiatons 1. INTRODUCTION In this paper we introduce an engine facility that abstracts the notion of timed preemption. In conjuction with the ability to maintain multiple control environments, engines allow a language to be extended with a variety of process abstraction facilities. Engines are represented as procedural objects that embody some computation. In this respect they resemble thunks (procedures of no arguments), which are sometimes called futures, for engines embody a computation that may be performed at some future time. However, futures are invoked with no limit on the time that may be required to complete their computation, whereas engines are run with a specified computation time limit after which control is returned to the invoker. In this sense engines may be thought of as bounded futures. By designing a base language with a few general abstraction mechanisms such as engines and continuations (which abstract the control environment), a powerful basis for building pro- gramming environments is provided. In this paper we are not introducing yet another process abstraction; rather, we are proposing an abstraction that allows implementation of arbitrary process abstractions through multiprogramming. This assures language extensibility and suitability to a wide range of applications. Concurrency issues, such as process synchronization primitives, are not central to our concerns in this paper. Though asynchronous preemption of a process implemented by multiprogramming with engines may introduce synchronization pathologies similar to those encountered in multiprocessing, they may be remedied with traditional concurrent programming techniques. Coroutines are a mechanism for maintaining multiple control contexts without multiprocessing, but they are fundamentally different from engines. Control is passed from one coroutine to another synchronously, i.e. under explicit control of the program, by means of operations such as resume and detach. An engine computation, on the other hand, may relinquish control either syn- chronously, by deliberately returning, or asynchronously by a timed preemption that involves no explicit action by the computation. Most computing environments provide a mechanism for timed preemption, such as a real-time clock capable of generating interrupts. In conjunction with a means of saving control state, such as continuations, these mechanisms may be used to implement engines. However, such mechanisms are frequently unavailable to the applications programmer, and when available they are usually imported from the operating system. As such, they tend to be inconvenient to use and always tThis material is based on work supported by the National Science Foundation under grant numbers MCS 83-04567, MCS 83-03325 and MCS 85-01277. 109