Shared Source CLI Essentials

Chapter 6. Regulating the Execution Engine

We’ve now seen how the CLI transforms high-level type descriptions into processor-specific code. This chapter examines what happens once this code has begun to run and what the execution engine needs to do to remain in control. Without a foolproof way to retain control, all of the unpacking, re-jiggering, checking, compiling, and linking of types that has been described to this point would be for nought. The runtime boundaries that are erected by the execution engine are one of its most desirable features, since they enable components to cooperate while remaining safely isolated.

Rotor piggybacks on two operating system abstractions, threads and exceptions, to control the execution state for a given process. Threads and exceptions are both related to the execution stack: a thread is home to the memory that makes up an execution stack, while exceptions create structure for that memory using a convention that helps protect its integrity at runtime.

Threads

Most programmers think of threads as a way to separate well-defined tasks into independent chunks of code, usually in conjunction with matching synchronization constructs. This usage is supported by the CLI, of course; chunks of code can run “on” threads whose schedules are dictated by the operating system’s threading implementation and by intertask dependencies. But threads in the CLI have another equally important role: they are the primary data structure for maintaining execution engine ...