Shared Source CLI Essentials

Exploring the Rest of the PAL

The rest of the PAL’s implementation has much less impact on the algorithms and operation of the execution engine than the topics already discussed in this chapter. It does, however, bear marks left by higher-level design choices, and perusing the code looking for these marks can be a very interesting exercise.

The code that provides network and file I/O, for example, is straightforward until the point where it hits semantic differences between Unix and the programming model of the CLI’s frameworks. As a final source-code expedition, we will briefly outline two areas in which these semantic mismatches require the PAL to install expensive impedance-matching code.

Locking File Regions in Multiple Processes

Unlike most flavors of Unix, Win32 supports region locking within opened files. Even so, implementing this feature in the PAL would be straightforward, were it not for the locked regions of opened files that must be accessible to all PAL processes. Because the feature is exposed by the Lock and Unlock methods of System.IO.FileStream in the base class library, locking must be valid across process group boundaries, and the data used to represent opened files must be stored in shared memory. As discussed in the previous section “Sharing Memory Between Unix Processes,” shared memory is a potential bottleneck to system throughput due to its region locking. Because of this, the data needed to implement file I/O, like all of the other handle-based implementations ...