README.panic | browse source | .tar.gz (sha1: not available yet)
By convention, Crux adopts an architectural style in which complex applications comprise dynamic collections of communicating, isolated processes. Each process has its own memory address space, opaque to the others.
The crux architecture envisions a social economy in which small programs, often individually published, define individual crux processes. Similarly: small, independent programs also define methods of composing processes into complete applications. Large systems are defined by a collection of small programs, each defining a simple process or a method for composing simple processes.
Each small Crux program is expected to perform a highly specialized task, hopefully in a simple, efficient way. Of course, "specialized", "simple", and "efficient" are in many ways subjective and situationally specific qualities.
The question thus arises: how can the designer of a complex application exercise some control of the overall efficiency of the system she is building?
Generally speaking, a program can be characterized by ratios relating the quantity of a programs input and output to:
Those broad metrics of efficiency apply both to individual processes, and to an overall composition of many small processes.
When evaluating the suitability of a small component, a designer must have some objective knowledge of the component's memory and compute cycle usage.
Concerning memory use, programs written for Crux should declare, in their documentation, one of three possibilities:
The program may allocate memory without bound, failing if the underlying platform can not provide the requested memory.
The program will never allocate more than X bytes, for some usefully small value of X.
The program will not allocate more than X bytes, where the value of X is externally specified when the program is invoked.
Given the choice between exceeding an allocation limit and failing via a call to "panic", a Crux program must call "panic".
Preferablly, a Crux program should opt for a hard allocation limit. If that is not possible a limit set when the program is invoked is next best. Finally, in exceptional cases, programs may not be able to impose an a priori limit on allocation.
The "chk" interface affords each of these three cases.
"chk_limit(0)" allows unbounded allocation (until the underlying allocator fails).
"chk_limit(X)" bound allocation to either a fixed value or one determined when a program is invoked, depending on what "X" is.
Note that programs which set the limit to a value supplied when the program is invoked, supplying a value of 0 means that the program runs with unbounded allocation.
crux n., pl. cruxes or cruces. 1. A crucial or vital moment; critical point. 2. The basic or essential thing. 3. A puzzling problem.
excerpted from — The American heritage dictionary of the english language (1981, ed. William Morris)
July 8, 2015 | the panic module June 13, 2015 | crux begins