Thunk
From Free net encyclopedia
The term thunk is a contrived word from computer science. It is also sometimes (nonstandardly) used as the past tense of "think" (e.g., Who'da thunk?), a phenomenon known as an analogy process in linguistics.
It has two possible meanings:
- a delayed computation (as in functional programming)
- a mapping of machine data from one system-specific form to another, usually for compatibility reasons. For example, running a 16-bit program on a 32-bit operating system may require a thunk from 16-bit addresses to 32-bit. Thunk in this sense may also refer to mappings from one calling convention to another or from one version of a library to another. This meaning is similar to the first—the "delayed computation" can be thought of as the "update" from the old format to the new.
Contents |
Thunk as delayed computation
Call by name
Implementations of the call by name and call by need evaluation strategies typically use a thunk to refer to the function's argument. In this context, the thunk is simply a computation that, when executed, returns the value (if any) of the argument.
In call-by-need, the thunk is replaced by its return value after its first execution. In languages with late binding, the "computation" performed by the thunk may include a lookup in the run-time context of the program to determine the current binding of a variable.
An early implementation of thunks for call-by-name was in early Algol 60 implementations.
Functional programming
In functional programming, a thunk is a nullary function—one that takes no arguments. Thunks are frequently used in strict languages as a means of simulating call-by-name evaluation; the thunk itself delays the computation of a function's argument, and the function forces the thunk to obtain the actual value. In this context, a thunk is often called a suspension. In Common Lisp, constant-valued thunks can be created with the constantly function: (constantly 5) evaluates to a nullary function that, when called, always yields the value 5.
Thunk as compatibility-mapping
OS/2 & Windows 16-bit address hack
A piece of code is executed to provide an address. The most common usage is in the Win16 / Win32 API, where thunking is used to convert a 16 bit address into a 32 bit equivalent or vice versa. One ubiquitous early example was "wsock32.dll", a thunking layer added to allow Win32 Internet applications to use the Win16 winsock.dll library originally written for Windows 3.11. Similar thunking was allowed from OS/2 to Win32 code in the Windows NT OS/2 subsystem and this was documented in the Resource Kit for Windows NT versions up to Windows 2000. Similar thunking was required in many cases in OS/2 2.x—while most of the operating system was 32-bit, many parts of the kernel and device drivers were 16-bit for compatibility reasons.
Thunks in dynamic linking
Certain implementations of relocatable code use local thunks to call library functions. Dynamic library calls in the code jump to thunks in a jump table; the jump table is replaced (by a dynamic linker) with short functions that either load the applicable library (as needed) or jump to the appropriate point in an already-loaded library. This form of thunk performs essentially the same task as the thunk-as-delayed-computation in call-by-need evaluation; the difference is largely one of perception.
Thunks in virtual memory
Software-based virtual memory systems may use a thunk to perform the mapping from virtual addresses to physical addresses; however, most modern systems do this computation in a specialized memory management unit in hardware. Microsoft Windows 3.0 and earlier, when running in real mode, used a thunk to replace any entry points to a function in a dynamic-link library or executable when the code segment containing that function was discarded (similar to swapped out in a conventional virtual memory system). This is an example of a software-based virtual memory system.