BOOL RTE

The architecture of the BOOL RTE (Run Time Environment, also  Run Time Engine depending on context) reflects the fundamental nature of BOOL. In particular, that refers to BOOL’s message-passing nature and the use of a parameter stack for passing data.  (BOOL call frames use a mechanism not susceptible to stack frame hacks.)

Separate entities in the BOOL environment communicate via message-passing, just as BOOL program objects do (and to a large extent, just as BOOL operates internally). As such, messaging is a native feature of the RTE and is supported in two basic forms.

Essentially, the BOOL RTE is like an operating system. It provides a set of standard systems available to running BOOL programs. The intent is that, as with Java and other platform-agnostic languages, BOOL programs are highly transportable to any platform with a BOOL RTE.

[For the record, I invented BOOL a few years before  Java appeared in 1995. At the time I had dreams of ‘releasing it to the wild’ and it becoming something like Java became.  When Java came out, I recall thinking, “Ah, this has much in common with BOOL!” The bytecode, the run-time engine, the portability… A key difference is that BOOL was never intended to have much utility. Plus, and I say this as a loving parent, BOOL is kinda ugly. That’s sort of intentional, so it won’t change.  Think early VW maybe.  Is what it is, does what it does.]

The BOOL RTE has the following sub-systems:

Workspace (WS):  The Workspace provides the ground on which all BOOL modules stand. Think backplane in a card rack. Modules are “plugged into” the WS to make them active and available.  This is done via a load or  a run message. The former is sufficient for library and data packages. Applications must be run, which puts them under control of the Executive sub-system.

The Workspace provides a standard messaging facility, called Ports, which are somewhat similar to TCP ports. An application running in the WS can request a Port binding that ties a given Port to that Application. Once bound, the Application receives all Messages sent to that Port.

Ports operate synchronously and asynchronously. In the first mode, a client sends a message to a Port and receives a reply. The mode is blocking; the client hangs until it receives its reply. Therefore services using this mode are required to be very fast. Maximum latency on Port requests is 1/10th second. (I just made that number up off the top of my head right now, so it will likely change.)

Longer requests use a polling system. The receiving application immediately returns a token to the client, who uses that token to poll the Port for updates.

Port conversations, like their TCP-alikes, are bound to applications on both ends and are designed to support multiple conversations simultaneously.

Executive (Exec): The Executive sub-system is responsible for managing the running threads of execution. It collaborates with the WS to know what modules are plugged in and requiring execution time. The WS/module interface has a number of semaphores reflecting the module’s state. The Exec uses these to keep tabs on the modules.

I haven’t decided entirely whether BOOL applications will be multi-threaded (perhaps), but the BOOL RTE is definitely intended to be multi-process!

Context (CTX): The Context sub-system is responsible for two related aspects: Locating resources (of any kind) requested by applications, and determining access rights to those resources. If an app wants to open a file, it must first ask the CTX where that file is and is access allowed.

The result of a (successful) CTX request message is an opaque token the app uses to access the resource. This token contains three things: a specific binding to the resource in question, the access rights of the user for this resource, a binding to the access methods of the resource. The token allows the service provider to determine the specific resource and how it is accessed.

Unsuccessful CTX requests fail due to not finding the resource or access not being permitted. Note that tokens can’t be faked, in part because they refer back to records in the CTX. The service provider checks with the CTX to validate the token.

Message Center (MC): The Message Center provides a way for any entity to communicate with any other entity.  The MC is very much like a post office where you can rent a post box. In this case, an application requests a Message Queue, which can be private or public. An application must explicitly share a private Queue. The MC lists public Queues in its directory.

Message Queues are very similar to Ports. The use the same data types, for example. MQs do not have a synchronous mode, however. Client apps always send messages asynchronously. Responses are sent to the  client’s Queue. Ports are intended for well-known services — typically RTE services, but can be application as well (an encryption service, for example).

All running application are required to have several Message Queue addresses, although they may virtual addresses to a single underlying Queue. There must be a System Queue and a Command Queue on the input side. There must also be an Output Queue for application output. There may also be an Input Queue and an Error Queue.

The Input, Output and Error Queues are basically the stdin, stdout and stderr streams used in most places. The Command Queue is intended for the application to receive requests from other applications. The System Queue is for the BOOL system to communicate with the app.

Data Center (DC): Handles allocations of large amounts of data (say for an image file), but in particular handles transfers of data (say loading that image from disk).

File System (FS): Handles all forms of persistent storage, loadable and permanent. In particular deals with name hierarchies and storage requirements.  {{Have an idea about a tag-based FS that might be an interesting fit here!}}

In the case of loading an image from disk, the DC would collaborate (via messages) with the FS to gain access to the file. It would use FS access methods to obtain the file data and load it into memory.

Input/Output System (IOS): Handles all forms of hardware, such as keyboards and monitors. Has the low-level access methods used by the FS to access the various kinds of drive hardware.  (So, returning to the image-loading example, the DS collaborates with the FS who collaborates with the IOS.)

All the sub-systems described above use well-known Ports:

Port 0: Workspace
Port 1: Executive
Port 2: CTX
Port 3: Message Center
Port 4: Data Center
Port 5: File System
Port 6: I/O System

Future articles will describe these subsystems in greater detail.

Advertisements
%d bloggers like this: