Thunk
From Wikipedia, the free encyclopedia
The word thunk has two meanings in computer science:
- 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.
In both senses, thunking refers to software implementations whose functionality depend on specific, often-inconsistent details of a particular system or hardware. Porting a thunked system can be difficult for this reason.
It is also used, in a jocular way, as the past tense and past participle of to think.
Contents |
[edit] Thunk as delayed computation
[edit] 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.
[edit] 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 or (in Scheme) a promise.
Thunks also arise naturally in other situations, for example in the implementation of constant functions, which may be useful in higher-order programming. In Common Lisp, constant functions are created by constantly
: (constantly 6)
evaluates to a thunk that, when called, always yields the value 6.
[edit] Thunk as compatibility-mapping
[edit] 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.
A flat thunk consists of a pair of dlls (one 32-bit and one 16-bit) that are used to translate calls from 32-bit code to 16-bit code. 16- and 32-bit memory addresses work very differently: 16-bit addresses consist of two parts, a pointer to a memory segment, and the offset from the start of that memory segment; whereas a 32bit process memory pointer consists of the absolute address of the memory being accessed. To allow the two dlls to communicate, some intermediate code must be used to translate memory addresses (pointers) between platforms.
[edit] 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.
[edit] 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.
[edit] Twunks
The Microsoft Windows thunks for the TWAIN API are called twunks (TWain thUNK).
[edit] Thunk applied generically to software development to describe a specific type of adapter
The original Microsoft thunk documentation describes thunk in terms of the (in)famous MakeProcInstance function (mov ax, XXXX; jmp <actual function address>). In many cases, one must do this type of generic translation or "glue" between two discrete entities. For example, when reading a foreign key from a database table an obvious requirement is to make the join to the related table. Thunk can be used as the term for making this explicit join within the constraints of a hand-created SQL stored procedure generator. Another example is in generic message interceptors (such as generic mouse-click interceptors within auto-enabling Ajax JavaScript libraries). The overall process of intercepting the generic mouse-click message, determining registered handlers, dispatching to those handlers, retrieving results, and applying results to the current page can be described as "thunking" the mouse-click event. In this sense, "to thunk" describes the overall process of detecting a condition that requires re-translation and/or re-packaging of the initial data along with the dispatching and/or handling computer code to support the required action.