1 Overview
The Racket run-time system is responsible for the implementation of primitive datatypes such as numbers and strings, the evaluation and/or JIT compilation of Racket bytecode, the macro expansion and compilation of Racket from source to bytecode, the allocation and reclamation of memory used during evaluation, and the scheduling of concurrent threads and parallel tasks.
Much of the language provided by racket/base is implemented in a more primitive dialect of Racket that is provided by the run-time system. Future versions of Racket are likely to move macro expansion, compilation, and many “primitive” functions into such Racket-implemented libraries, instead of having them built into the run-time system.
1.1 “Scheme” versus “Racket”
The old name for Racket was “PLT Scheme,” and the core compiler and run-time system used to be called “MzScheme.” The old names are entrenched in Racket internals, to the point that most C bindings defined in this manual start with scheme_. In principle, they all should be renamed to start racket_.
1.2 Building Racket from Source
The normal Racket distribution includes ".rkt" sources for collection-based libraries. After modifying library files, run raco setup (see raco setup: Installation Management) to rebuild installed libraries.
The normal Racket distribution does not include the C sources for Racket’s run-time system. To build Racket from scratch, download a source distribution from http://download.racket-lang.org; detailed build instructions are in the "README" file in the top-level "src" directory. You can also get the latest sources from the git repository at https://github.com/racket/racket, but beware that the repository is one step away from a normal source distribution, and it provides build modes that are more suitable for developing Racket itself; see "INSTALL.txt" in the git repository for more information.
1.3 CGC versus 3m
Before mixing any C code with Racket, first decide whether to use the 3m variant of Racket, the CGC variant of Racket, or both:
3m : the main variant of Racket, which uses precise garbage collection and requires explicit registration of pointer roots and allocation shapes. The precise garbage collector may move its objects in memory during a collection.
CGC : the original variant of Racket, where memory management depends on a conservative garbage collector. The conservative garbage collector can automatically find references to managed values from C local variables and (on some platforms) static variables, and it does not move allocated objects.
At the C level, working with CGC can be much easier than working with 3m, but overall system performance is typically better with 3m.
1.4 Embedding and Extending Racket
The Racket run-time system can be embedded into a larger program; see Embedding into a Program for more information. As an alternative to embedding, the racket executable can also be run in a subprocess, and that choice may be better for many purposes. On Windows, MzCom provides another option.
The Racket run-time system can be extended with new C-implemented functions. Historically, writing an extension could provide performance benefits relative to writing pure Racket code, but Racket performance has improved to the point that performance benefits of writing C code (if any) are usually too small to justify the maintenance effort. For calling functions that are provided by a C-implemented library, meanwhile, using with foreign-function interface within Racket is a better choice than writing an extension of Racket to call the library.
1.5 Racket and Places
Each Racket place corresponds to a separate OS-implemented thread. Each place has its own memory manager. Pointers to GC-managed memory cannot be communicated from one place to another, because such pointers in one place are invisible to the memory manager of another place.
When place support is enabled, static variables at the C level generally cannot hold pointers to GC-managed memory, since the static variable may be used from multiple places. For some OSes, a static variable can be made thread-local, in which case it has a different address in each OS thread, and each different address can be registered with the GC for a given place.
In an embedding application, the OS thread that originally calls scheme_basic_env is the OS thread of the original place. When scheme_basic_env is called a second time to reset the interpreter, it can be called in an OS thread that is different from the original call to scheme_basic_env. Thereafter, the new thread is the OS thread for the original place.
1.6 Racket and Threads
Racket implements threads for Racket programs without aid from the operating system, so that Racket threads are cooperative from the perspective of C code. On Unix, stand-alone Racket uses a single OS-implemented thread. On Windows and Mac OS X, stand-alone Racket uses a few private OS-implemented threads for background tasks, but these OS-implemented threads are never exposed by the Racket API.
Racket can co-exist with additional OS-implemented threads, but the additional OS threads must not call any scheme_ function. Only the OS thread representing a particular place can call scheme_ functions. (This restriction is stronger than saying all calls for a given place must be serialized across threads. Racket relies on properties of specific threads to avoid stack overflow and garbage collection.) In an embedding application, for the original place, only the OS thread used to call scheme_basic_env can call scheme_ functions. For any other place, only the OS thread that is created by Racket for the place can be used to call scheme_ functions.
See Threads for more information about threads, including the possible effects of Racket’s thread implementation on extension and embedding C code.
1.7 Racket, Unicode, Characters, and Strings
A character in Racket is a Unicode code point. In C, a character
value has type mzchar, which is an alias for unsigned —
Only a few Racket functions use mzchar*. Instead, most functions accept char* strings. When such byte strings are to be used as a character strings, they are interpreted as UTF-8 encodings. A plain ASCII string is always acceptable in such cases, since the UTF-8 encoding of an ASCII string is itself.
See also Strings and String Encodings.
1.8 Integers
Racket expects to be compiled in a mode where short is a 16-bit integer, int is a 32-bit integer, and intptr_t has the same number of bits as void*. The long type can match either int or intptr_t, depending on the platform. The mzlonglong type has 64 bits for compilers that support a 64-bit integer type, otherwise it is the same as intptr_t; thus, mzlonglong tends to match long long. The umzlonglong type is the unsigned version of mzlonglong.