View source for Thunk

{{otheruses}}{{wiktionary}}
{{short description|Type of subroutine}}
{{use dmy dates|date=January 2020|cs1-dates=y}}
In [[computer programming]], a '''thunk''' is a [[subroutine]] used to inject a calculation into another subroutine. Thunks are primarily used to delay a calculation until its result is needed, or to insert operations at the beginning or end of the other subroutine. They have many other applications in [[Code generation (compiler)|compiler code generation]] and [[modular programming]].

The term originated as a whimsical [[English irregular verbs|irregular]] form of the verb ''think''. It refers to the original use of thunks in [[ALGOL 60]] compilers, which required special analysis (thought) to determine what type of routine to generate.<ref>
Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a ''thunk'', which is 'the past tense of "think" at two in the morning'. See: {{cite book
| last1                 = Raymond
| first1                = Eric S.
| author-link1          = Eric S. Raymond
| editor1-last          = Raymond
| editor1-first         = Eric S.
| editor1-link          = Eric S. Raymond
| title                 = The New Hacker's Dictionary
| url                   = https://books.google.com/books?id=g80P_4v4QbIC&q=thunk&pg=PA445
| publisher             = MIT Press
| date      = 1996
| page                  = 445
| isbn                  = 9780262680929
| access-date            = 2015-05-25
}}
</ref><ref>See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."</ref>

==Background==
The early years of [[compiler]] research saw broad experimentation with different [[evaluation strategy|evaluation strategies]]. A key question was how to compile a subroutine call if the arguments can be arbitrary mathematical expressions rather than constants. One approach, known as "[[call by value]]", calculates all of the arguments before the call and then passes the resulting values to the subroutine. In the rival "[[call by name]]" approach, the subroutine receives the unevaluated argument expression and must evaluate it.

A simple implementation of "call by name" might substitute the code of an argument expression for each appearance of the corresponding parameter in the subroutine, but this can produce multiple versions of the subroutine and multiple copies of the expression code. As an improvement, the compiler can generate a helper subroutine, called a ''thunk'', that calculates the value of the argument. The address and environment{{efn|A thunk is an early limited type of [[Closure (computer programming)|closure]]. The environment passed for the thunk is that of the expression, not that of the called routine.<ref>{{cite journal
 |     title = Comments on the Implementation of Recursive Procedures and Blocks in ALGOL
 |    author = E. T. Irons
 |   journal = Communications of the ACM
 |      date = January 1, 1961
 |    volume = 4
 |     issue = 1
 | publisher = Association for Computing Machinery (ACM)
 |      issn = 0001-0782
 |       doi = 10.1145/366062.366090
 |     pages = 65&ndash;69
 | s2cid=42778823
 |doi-access = free
 }}
 </ref>}} of this helper subroutine are then passed to the original subroutine in place of the original argument, where it can be called as many times as needed. Peter Ingerman first described thunks in reference to the ALGOL 60 programming language, which supports call-by-name evaluation.<ref>{{cite journal | last=Ingerman | first=P. Z. | title=Thunks: a way of compiling procedure statements with some comments on procedure declarations | journal=Communications of the ACM | publisher=Association for Computing Machinery (ACM) | volume=4 | issue=1 | date=1961-01-01 | issn=0001-0782 | doi=10.1145/366062.366084 | pages=55–58 | s2cid=14646332 | doi-access=free }}</ref>

==Applications==

===Functional programming===
Although the software industry largely standardized on call-by-value and [[Call by reference|call-by-reference]] evaluation,<ref>{{cite book|last=Scott|first=Michael|title=Programming Language Pragmatics|year=2009|page=395}}</ref> active study of call-by-name continued in the [[functional programming]] community. This research produced a series of [[lazy evaluation]] programming languages in which some variant of call-by-name is the standard evaluation strategy. Compilers for these languages, such as the [[Glasgow Haskell Compiler]], have relied heavily on thunks, with the added feature that the thunks save their initial result so that they can avoid recalculating it;<ref>{{cite book|first=Simon|last=Marlow|title=Parallel and Concurrent Programming in Haskell|year=2013|page=10}}</ref> this is known as [[memoization]] or [[Evaluation strategy#Call by need|call-by-need]].

Functional programming languages have also allowed programmers to explicitly generate thunks. This is done in [[source code]] by wrapping an argument expression in an [[anonymous function]] that has no parameters of its own. This prevents the expression from being evaluated until a receiving function calls the anonymous function, thereby achieving the same effect as call-by-name.<ref>{{cite book|first=Christian|last=Queinnec|title=Lisp in Small Pieces|year=2003|page=176}}</ref> The adoption of anonymous functions into other programming languages has made this capability widely available.

===Object-oriented programming===
Thunks are useful in [[object-oriented programming]] platforms that allow a [[Class (computer programming)|class]] to [[multiple inheritance|inherit multiple interfaces]], leading to situations where the same [[Method (computer programming)|method]] might be called via any of several interfaces. The following code illustrates such a situation in [[C++]].

<syntaxhighlight lang="cpp">
class A {
 public:
  virtual int Access() const { return value_; }

 private:
  int value_;
};

class B {
 public:
  virtual int Access() const { return value_; }

 private:
  int value_;
};

class C : public A, public B {
 public:
  int Access() const override { return better_value_; }

 private:
  int better_value_;
};

int use(B *b) { return b->Access(); }

int main() {
  // ...
  B some_b;
  use(&some_b);
  C some_c;
  use(&some_c);
}
</syntaxhighlight>

In this example, the code generated for each of the classes A, B and C will include a [[dispatch table]] that can be used to call {{code|Access}} on an object of that type, via a reference that has the same type. Class C will have an additional dispatch table, used to call {{code|Access}} on an object of type C via a reference of type B. The expression {{code|b->Access()}} will use B's own dispatch table or the additional C table, depending on the type of object b refers to. If it refers to an object of type C, the compiler must ensure that C's {{code|Access}} implementation receives an [[this (computer programming)|instance address]] for the entire C object, rather than the inherited B part of that object.<ref name=BS99>{{cite journal
 |last1      = Stroustrup
 |first1     = Bjarne
 |title      = Multiple Inheritance for C++
 |date=Fall 1989
 |journal  = Computing Systems
 |publisher  = [[USENIX]]
 |volume = 1
 |number = 4
 |url        = https://www.usenix.org/legacy/publications/compsystems/1989/fall_stroustrup.pdf
 |access-date = 4 August 2014
}}</ref>

As a direct approach to this pointer adjustment problem, the compiler can include an integer offset in each dispatch table entry. This offset is the difference between the reference's address and the address required by the method implementation. The code generated for each call through these dispatch tables must then retrieve the offset and use it to adjust the instance address before calling the method.

The solution just described has problems similar to the naïve implementation of call-by-name described earlier: the compiler generates several copies of code to calculate an argument (the instance address), while also increasing the dispatch table sizes to hold the offsets. As an alternative, the compiler can generate an ''adjustor thunk'' along with C's implementation of {{code|Access}} that adjusts the instance address by the required amount and then calls the method. The thunk can appear in C's dispatch table for B, thereby eliminating the need for callers to adjust the address themselves.<ref name=DH01>{{cite conference
 |conference = 11th OOPSLA 1996: San Jose, California, USA
 |book-title = Proceedings of the 1996 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications, OOPSLA 1996, San Jose, California, USA, October 6-10, 1996
 |isbn       = 0-89791-788-X
 |last1      = Driesen
 |first1     = Karel
 |last2      = Hölzle
 |first2     = Urs
 |title      = The Direct Cost of Virtual Function Calls in C++
 |year       = 1996
 |publisher  = [[Association for Computing Machinery|ACM]]
 |url        = http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla96.pdf
 |archive-url= http://web.archive.org/web/20191229115559/https://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla96.pdf
 |archive-date= 29 December 2019
 
 |access-date = 24 February 2011
}}</ref>

===Interoperability===
Thunks have been widely used to provide interoperability between software modules whose routines cannot call each other directly. This may occur because the routines have different [[calling convention]]s, run in different [[CPU modes]] or [[address space]]s, or at least one runs in a [[virtual machine]]. A compiler (or other tool) can solve this problem by generating a thunk that automates the additional steps needed to call the target routine, whether that is transforming arguments, copying them to another location, or switching the CPU mode. A successful thunk minimizes the extra work the caller must do compared to a normal call.

Much of the literature on interoperability thunks relates to various [[Wintel]] platforms, including [[MS-DOS]], [[OS/2]],<ref name="Calcote_1995">{{cite journal |author-first=John |author-last=Calcote |title=Thunking: Using 16-Bit Libraries in OS/2 2.0 |journal=OS/2 Developer Magazine |volume=7 |issue=3 |pages=48–56 |date=May 1995 |url=https://archive.org/details/Readme_20181018/OS2DevMag-V7N3/page/48/mode/2up}}</ref> [[Microsoft Windows|Windows]]<ref name="King_1994">{{cite book |title=Inside Microsoft Windows 95 |author-first=Adrian |author-last=King |publisher=[[Microsoft Press]] |edition=2nd |date=1994 |isbn=1-55615-626-X <!--|ISBN=978-1-55615-626-7 --> |location=Redmond, Washington, USA}}</ref><ref name="Microsoft_1995">{{cite book |title=Programmer's Guide to Microsoft Windows 95: Key Topics on Programming for Windows from the Microsoft Windows Development Team |work=Technical Reference |author=<!-- staff writers --> |publisher=[[Microsoft Press]] |edition=1st |date=1995-07-01 |isbn=1-55615-834-3 <!--|ISBN=978-1-55615-834-6 --> |location=Redmond, Washington, USA |url=https://books.google.com/books?id=MLZQAAAAMAAJ |access-date=2016-05-26}}</ref><ref name="Hazzah_1997">{{cite book |title=Writing Windows VxDs and Device Drivers - Programming Secrets for Virtual Device Drivers |author-first=Karen |author-last=Hazzah |publisher=R&D Books / [[Miller Freeman, Inc.]] |location=Lawrence, Kansas, USA |edition=2nd printing, 2nd |date=1997 |isbn=0-87930-438-3 <!--|ISBN=978-0-87930-438-6 -->}}</ref><ref name="Kauler_1997">{{cite book |title=Windows Assembly Language and Systems Programming - 16- and 32-Bit Low-Level Programming for the PC and Windows |author-first=Barry |author-last=Kauler |author-link=Barry Kauler |publisher=R&D Books / [[Miller Freeman, Inc.]] |location=Lawrence, Kansas, USA |edition=2nd |date=August 1997 |isbn=0-87930-474-X <!--|ISBN=978-0-87930-474-4 -->}}</ref> and [[.NET Framework|.NET]], and to the transition from [[16-bit]] to [[32-bit]] memory addressing. As customers have migrated from one platform to another, thunks have been essential to support [[legacy software]] written for the older platforms. [[UEFI CSM]] is another example to do thunk for legacy [[boot loader]]s.

The transition from 32-bit to 64-bit code on x86 also uses a form of thunking ([[WoW64]]). However, because the x86-64 address space is larger than the one available to 32-bit code, the old "generic thunk" mechanism could not be used to call 64-bit code from 32-bit code.<ref>{{cite web |title=Why can't you thunk between 32-bit and 64-bit Windows? |url=https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20523 |website=The Old New Thing |date=20 October 2008}}</ref> The only case of 32-bit code calling 64-bit code is in the WoW64's thunking of Windows APIs to 32-bit.

===Overlays and dynamic linking===
On systems that lack automatic [[virtual memory]] hardware, thunks can implement a limited form of virtual memory known as [[Overlay (programming)|overlays]]. With overlays, a developer divides a program's code into segments that can be loaded and unloaded independently, and identifies the [[entry point]]s into each segment. A segment that calls into another segment must do so indirectly via a [[branch table]]. When a segment is in memory, its branch table entries jump into the segment. When a segment is unloaded, its entries are replaced with "reload thunks" that can reload it on demand.<ref>{{cite journal|first=Walter|last=Bright|title=Virtual Memory For 640K DOS|journal=Dr. Dobb's Journal|date=1990-07-01|url=http://www.drdobbs.com/virtual-memory-for-640k-dos/184402189|access-date=2014-03-06}}</ref>

Similarly, systems that [[dynamic linking|dynamically link]] modules of a program together at run-time can use thunks to connect the modules. Each module can call the others through a table of thunks that the linker fills in when it loads the module. This way the modules can interact without prior knowledge of where they are located in memory.<ref name="Levine_1999"/>

==See also==
===Thunk technologies===
* [[DOS Protected Mode Interface]] (DPMI)
* [[DOS Protected Mode Services]] (DPMS)
* [[J/Direct]]
* Microsoft Layer for Unicode
* [[Platform Invocation Services]]
* [[Win32s]]
* [[Windows on Windows]]
* [[Compatibility Support Module]]
* [[WoW64]]
* [[libffi]]
* [[Wine (software)|Wine]] (since version 9.0)<ref>{{cite web |last1=Julliard |first1=Alexandre |title=Wine 9.0 |url=https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0 |website=WineHQ Gitlab |access-date=10 March 2025}}</ref>

===Related concepts===
* [[Anonymous function]]
* [[Futures and promises]]
* [[Remote procedure call]]
* [[Shim (computing)]]
* [[Trampoline (computing)]]
* [[Reducible expression]]

==Notes==
{{Notelist}}

==References==
{{reflist|refs=
<ref name="Levine_1999">{{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}} Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]</ref>
}}

[[Category:Computing terminology]]
[[Category:Functional programming]]