Plan 9 is a distributed computing environment. It is assembled from separate machines acting as CPU servers, file servers, and terminals. The pieces are connected by a single file-oriented protocol and local name space operations. By building the system from distinct, specialised components rather than from similar general-purpose components, Plan 9 achieves levels of efficiency, security, simplicity, and reliability seldom realised in other distributed systems. This paper discusses the building blocks, interconnections, and conventions of Plan 9. Introduction. Plan 9 is a general-purpose, multi-user, portable distributed system implemented on a variety of computers and networks. It lacks a number of features often found in other distributed systems, including (i) A uniform distributed name space, (ii) Process migration,

Traditional first-class continuation mechanisms allow a captured continuation to be invoked multiple times. Many continuations, however, are invoked only once. This paper introduces one-shot continuations, shows how they interact with traditional multi-shot continuations, and describes a stack-based implementation of control that handles both one-shot and multi-shot continuations. The implementation eliminates the copying overhead for one-shot continuations that is inherent in multi-shot continuations. 1 Introduction Scheme [5] and some implementations of ML [17] provide continuations as first-class data objects. Continuations can be used to implement, at the source level, a number of interesting control features, such as loops, nonlocal exits, nonblind backtracking [22], nondeterministic computations [10, 14], and coroutines [7]. Source-level implementations of thread systems [9, 15, 21], especially in the area of graphical user interfaces (GUIs) [12, 13, 20, 23], are an important ...

Machine" [BB90], except that there are no "cooling" and "heating" transitions (the process sets of this semantics can be thought of as perpetually "hot" solutions). The concurrent evaluation relation extends "7\Gamma!" to finite sets of terms (i.e., processes) and adds additional rules for process creation, channel creation, and communication. We assume a set of process identifiers, and define the set of processes and process sets as: ß 2 ProcId process IDs p = hß; ei 2 Proc = (ProcId \Theta Exp) processes P 2 Fin(Proc) process sets We often write a process as hß; E[e]i, where the evaluation context serves the role of the program counter, marking the current state of evaluation. Definition4. A process set P is well-formed if for all hß; ei 2 P the following hold: -- FV(e) = ; (e is closed), and -- there is no e 0 6= e, such that hß; e 0 i 2 P. It is occasionally useful to view well-formed process sets as finite maps from ProcId to Exp. If P is a finite set of process state...

This paper describes eXene, a user interface toolkit implemented in a concurrent extension of Standard ML. The design and use of eXene is inextricably woven with the presence of multiple threads and a high-level language. These features replace the object-oriented design of most toolkits, and provide a better basis for dealing with the complexities of user interfaces, especially concerning such aspects as type safety, extensibility, component reuse and the balance between the user interface and other parts of the program. 1

This paper proposes to combine two seemingly opposed programming models for building massively concurrent network services: the event-driven model and the multithreaded model. The result is a hybrid design that offers the best of both worlds—the ease of use and expressiveness of threads and the flexibility and performance of events. This paper shows how the hybrid model can be implemented entirely at the application level using concurrency monads in Haskell, which provides type-safe abstractions for both events and threads. This approach simplifies the development of massively concurrent software in a way that scales to real-world network services. The Haskell implementation supports exceptions, symmetrical multiprocessing, software transactional memory, asynchronous I/O mechanisms and application-level network protocol stacks. Experimental results demonstrate that this monad-based approach has good performance: the threads are extremely lightweight (scaling to ten million threads), and the I/O performance compares favorably to that of Linux NPTL. Categories and Subject Descriptors D.1.1 [Programming techniques]:

Concurrent programs require high-level abstractions in order to manage complexity and enable compositional reasoning. In this paper, we introduce a novel concurrency abstraction, dubbed transactional events, which combines first-class synchronous message passing events with all-or-nothing transactions. This combination enables simple solutions to interesting problems in concurrent programming. For example, guarded synchronous receive can be implemented as an abstract transactional event, whereas in other languages it requires a non-abstract, non-modular protocol. As another example, three-way rendezvous can be implemented as an abstract transactional event, which is impossible using first-class events alone. Both solutions are easy to code and easy to reason about. The expressive power of transactional events arises from a sequencing combinator whose semantics enforces an all-or-nothing transactional property – either both of the constituent events synchronize in sequence or neither of them synchronizes. This sequencing combinator, along with a non-deterministic choice combinator, gives transactional events the compositional structure of a monad-with-plus. We provide a formal semantics for transactional events and give a detailed account of an implementation.

The Plan 9 window system, 8 1 /2 , is a modest-sized program of novel design. It provides ASCII I/O and bitmap graphic services to both local and remote client programs by offering a multiplexed file service to those clients. It serves traditional UNIX files like /dev/tty as well as more unusual ones that provide access to the mouse and the raw screen. Bitmap graphics operations are provided by serving a file called /dev/bitblt that interprets client messages to perform raster operations. The file service that 8 1 /2 offers its clients is identical to that it uses for its own implementation, so it is fundamentally no more than a multiplexer. This architecture has some rewarding symmetries and can be implemented compactly

. The idea of making synchronous operations into first-class values is an important one for supporting abstraction and modularity in concurrent programs. This design principle has been used with great success in the concurrent language CML, but what are the limitations of this approach? This paper explains the rationale for first-class synchronous operations, and discusses their use in CML. It also presents some recent and fundamental results about the expressiveness of rendezvous primitives, which define the limitations of synchronous abstractions. 1 Introduction Abstraction is a key tool for managing complexity. The design of programming languages is one area where application of this idea has paid significant dividends. Languages have evolved from providing a fixed set of abstractions of the underlying hardware, such as arithmetic expressions and arrays, to providing support for programmer-defined abstractions, such as abstract data-types and higher-order procedures. By providing ...

The event-driven, or reactive, programming style of the contemporary CUt is a major reason they are difficult to program. This is compounded in a distributed application. The reactive style, however, reflects the mismatch between multithreaded interfaces and a single threaded process, and is actually the equivalent of continuation passing style, a source code transformation used by some compilers. Using continuations for callbacks eliminates much of the difficulty of the reactive style. We describe a toolkit for managing the multiple threads of control which can be combined with existing CUI toolkits and which supports distributed applications.

Events play an important role in the construction of most software that involves interaction or simulation. Typically, programmers make use of a fixed set of low level events supplied by a window system, possibly augmented with timers and UI components. Event handling generally involves some interpretation of these event occurrences, followed by external actions or modifications to program state. It is possible to extend the event paradigm by using event interpretation to synthesize new kinds of events tailored specifically for a domain or application. In turn, these new events may be used to synthesize yet others, and so on, to an arbitrarily sophisticated degree. This programming paradigm, which we call event-oriented programming, aids in the factoring of programs into understandable and reusable pieces. We propose a declarative approach to event-oriented programming, based on a powerfully expressive event language with a lightweight notation. We illustrate this new approach throug...