Changeset 0583b47b
- Timestamp:
- Apr 20, 2021, 5:17:31 PM (3 years ago)
- Branches:
- ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
- Children:
- 341aa39
- Parents:
- ddd473f (diff), 59f3f61 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)links above to see all the changes relative to each parent. - Location:
- doc/theses/andrew_beach_MMath
- Files:
-
- 4 deleted
- 3 edited
- 2 moved
-
Makefile (modified) (2 diffs)
-
exception-hierarchy.fig (moved) (moved from doc/theses/andrew_beach_MMath/exceptionHierarchy.fig)
-
features.tex (modified) (12 diffs)
-
stack-marking.fig (moved) (moved from doc/theses/andrew_beach_MMath/stackMarking.fig)
-
thesis-frontpgs.tex (deleted)
-
thesis.bib (deleted)
-
thesis.tex (deleted)
-
uw-ethesis.cls (deleted)
-
uw-ethesis.tex (modified) (6 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/Makefile
rddd473f r0583b47b 1 1 ### Makefile for Andrew Beach's Masters Thesis 2 2 3 DOC = uw-ethesis.pdf 4 BASE = ${DOC:%.pdf=%} # remove suffix 5 # directory for latex clutter files 6 BUILD = build 7 TEXSRC = $(wildcard *.tex) 8 FIGSRC = $(wildcard *.fig) 9 BIBSRC = $(wildcard *.bib) 10 STYSRC = $(wildcard *.sty) 11 CLSSRC = $(wildcard *.cls) 12 TEXLIB = .:../../LaTeXmacros:${BUILD}: # common latex macros 13 BIBLIB = .:../../bibliography # common citation repository 3 DOC=uw-ethesis.pdf 4 BUILD=out 5 TEXSRC=$(wildcard *.tex) 6 FIGSRC=$(wildcard *.fig) 7 BIBSRC=$(wildcard *.bib) 8 STYSRC=$(wildcard *.sty) 9 CLSSRC=$(wildcard *.cls) 10 TEXLIB= .:../../LaTeXmacros:${BUILD}: 11 BIBLIB= .:../../bibliography 14 12 15 MAKEFLAGS = --no-print-directory # --silent 16 VPATH = ${BUILD} 13 # Since tex programs like to add their own file extensions: 14 BASE= ${DOC:%.pdf=%} 15 16 RAWSRC=${TEXSRC} ${BIBSRC} ${STYSRC} ${CLSSRC} 17 FIGTEX=${FIGSRC:%.fig=${BUILD}/%.tex} 17 18 18 19 ### Special Rules: 19 20 20 21 .PHONY: all clean deepclean 21 .PRECIOUS: %.dvi %.ps # do not delete intermediate files22 22 23 23 ### Commands: 24 LATEX = TEXINPUTS=${TEXLIB} && export TEXINPUTS &&latex -halt-on-error -output-directory=${BUILD}25 BIBTEX =BIBINPUTS=${BIBLIB} bibtex26 GLOSSARY =INDEXSTYLE=${BUILD} makeglossaries-lite24 LATEX=TEXINPUTS=${TEXLIB} latex -halt-on-error -output-directory=${BUILD} 25 BIBTEX=BIBINPUTS=${BIBLIB} bibtex 26 GLOSSARY=INDEXSTYLE=${BUILD} makeglossaries-lite 27 27 28 ### Rules and Recip es:28 ### Rules and Recipies: 29 29 30 30 all: ${DOC} 31 31 32 ${BUILD}/%.dvi: ${TEXSRC} ${FIGSRC:.fig=.tex} ${BIBSRC} ${STYSRC} ${CLSSRC} Makefile | ${BUILD} 32 # The main rule, it does all the tex/latex processing. 33 ${BUILD}/${BASE}.dvi: ${RAWSRC} ${FIGTEX} Makefile | ${BUILD} 33 34 ${LATEX} ${BASE} 34 35 ${BIBTEX} ${BUILD}/${BASE} … … 37 38 ${LATEX} ${BASE} 38 39 40 # Convert xfig output to tex. (Generates \special declarations.) 41 ${FIGTEX}: ${BUILD}/%.tex: %.fig | ${BUILD} 42 fig2dev -L eepic $< > $@ 43 44 # Step through dvi & postscript to handle xfig specials. 45 %.pdf : ${BUILD}/%.dvi 46 dvipdf $^ $@ 47 39 48 ${BUILD}: 40 49 mkdir $@ 41 50 42 %.pdf : ${BUILD}/%.ps | ${BUILD}43 ps2pdf $<44 45 %.ps : %.dvi | ${BUILD}46 dvips $< -o $@47 48 %.tex : %.fig | ${BUILD}49 fig2dev -L eepic $< > ${BUILD}/$@50 51 %.ps : %.fig | ${BUILD}52 fig2dev -L ps $< > ${BUILD}/$@53 54 %.pstex : %.fig | ${BUILD}55 fig2dev -L pstex $< > ${BUILD}/$@56 fig2dev -L pstex_t -p ${BUILD}/$@ $< > ${BUILD}/$@_t57 58 51 clean: 59 @rm -frv ${BUILD} *.fig.bak52 -@rm -rv ${BUILD} 60 53 61 54 deepclean: clean 62 -@rm - fv ${DOC}55 -@rm -v ${DOC} -
doc/theses/andrew_beach_MMath/features.tex
rddd473f r0583b47b 3 3 This chapter covers the design and user interface of the \CFA 4 4 exception-handling mechanism (EHM). % or exception system. 5 While an EHM is free to add many features, 6 the following overview covers the basic features that all EHMs use, but it is not an 7 exhaustive list of everything an EHM can do. 5 6 We will begin with an overview of EHMs in general. It is not a strict 7 definition of all EHMs nor an exaustive list of all possible features. 8 However it does cover the most common structure and features found in them. 8 9 9 10 % We should cover what is an exception handling mechanism and what is an … … 14 15 These terms are sometimes also known as throw and catch but this work uses 15 16 throw/catch as a particular kind of raise/handle. 16 These are the two parts a programmer writes and so17 are the only two pieces of the EHM that have language syntax.17 These are the two parts that the user will write themselves and may 18 be the only two pieces of the EHM that have any syntax in the language. 18 19 19 20 \subparagraph{Raise} 20 The raise is the starting point for exception handling and usually how \PAB{This sentence is cut off.} 21 Some well known examples include the @throw@ statement of \Cpp and Java and 22 the \lstinline[language=Python]{raise} statement from Python. 23 24 For this overview, a raise starts the handling of an 25 exception, which is called \newterm{raising} an exception. This simple description is sufficient 26 for the overview. 21 The raise is the starting point for exception handling. It marks the beginning 22 of exception handling by \newterm{raising} an excepion, which passes it to 23 the EHM. 24 25 Some well known examples include the @throw@ statements of \Cpp and Java and 26 the \codePy{raise} statement from Python. In real systems a raise may preform 27 some other work (such as memory management) but for the purposes of this 28 overview that can be ignored. 27 29 28 30 \subparagraph{Handle} 29 The purpose of raising an exception is to run user code to address (handle) the 30 issue found at the raise point. 31 The @try@ statement of \Cpp illustrates a common approach for specifying multiple handlers. 32 A handler has three common features: the scope in which it applies, an 33 exception label that describes what exceptions it can handle, and code to run 34 that deals with the raised issue. 35 Each handler can handle exceptions raised in the region matching its 36 exception label. For multiple matches, different EHMs have different rules for matching an exception to a handler label, 37 such as ``best match" or ``first found". 31 The purpose of most exception operations is to run some user code to handle 32 that exception. This code is given, with some other information, in a handler. 33 34 A handler has three common features: the previously mentioned user code, a 35 region of code they cover and an exception label/condition that matches 36 certain exceptions. 37 Only raises inside the covered region and raising exceptions that match the 38 label can be handled by a given handler. 39 Different EHMs will have different rules to pick a handler 40 if multipe handlers could be used such as ``best match" or ``first found". 41 42 The @try@ statements of \Cpp, Java and Python are common examples. All three 43 also show another common feature of handlers, they are grouped by the covered 44 region. 38 45 39 46 \paragraph{Propagation} 40 After an exception is raised , comes the most complexstep for the41 EHM: finding and setting up the handler. Th is propagation of exception from raise to handler can be broken up into three42 different tasks: searching, matching, and 43 installing the handler so it can execute.47 After an exception is raised comes what is usually the biggest step for the 48 EHM: finding and setting up the handler. The propogation from raise to 49 handler can be broken up into three different tasks: searching for a handler, 50 matching against the handler and installing the handler. 44 51 45 52 \subparagraph{Searching} 46 The EHM searches for possible handlers that can be used to handle 47 the exception. Searching is usually independent of the exception that is 48 thrown and instead depends on the call stack: current function, its caller 49 and repeating down the stack. 53 The EHM begins by searching for handlers that might be used to handle 54 the exception. Searching is usually independent of the exception that was 55 thrown as it looks for handlers that have the raise site in their covered 56 region. 57 This includes handlers in the current function, as well as any in callers 58 on the stack that have the function call in their covered region. 50 59 51 60 \subparagraph{Matching} 52 For each handler found, it compares the raised exception with the handler label to see which one is the 53 best match, and hence, which one should be used to handle the exception. 54 In languages where the best match is the first match, these two steps are often 55 intertwined, \ie a match check is performed immediately after the search finds 61 Each handler found has to be matched with the raised exception. The exception 62 label defines a condition that be use used with exception and decides if 63 there is a match or not. 64 65 In languages where the first match is used this step is intertwined with 66 searching, a match check is preformed immediately after the search finds 56 67 a possible handler. 57 68 58 69 \subparagraph{Installing} 59 After a handler is chosen ,it must be made ready to run.60 Th is step varieswidely to fit with the rest of the61 design of the EHM. The installation step might be trivial or it c anbe70 After a handler is chosen it must be made ready to run. 71 The implementation can vary widely to fit with the rest of the 72 design of the EHM. The installation step might be trivial or it could be 62 73 the most expensive step in handling an exception. The latter tends to be the 63 74 case when stack unwinding is involved. 64 An alternate action occurs if no appropriate handler is found, then some implicit action 65 is performed. This step is only required with unchecked 66 exceptions as checked exceptions (Java) promise a handler is always found. The implicit action 67 also installs a handler but it is a default handle that may be 68 installed differently. 75 76 If a matching handler is not guarantied to be found the EHM will need a 77 different course of action here in the cases where no handler matches. 78 This is only required with unchecked exceptions as checked exceptions 79 (such as in Java) can make than guaranty. 80 This different action can also be installing a handler but it is usually an 81 implicat and much more general one. 69 82 70 83 \subparagraph{Hierarchy} 71 Some EHM (\CFA, Java) organize exceptions in a hierarchical structure.72 This strategy is borrowed fromobject-orientated languages where the84 A common way to organize exceptions is in a hierarchical structure. 85 This is especially true in object-orientated languages where the 73 86 exception hierarchy is a natural extension of the object hierarchy. 74 87 75 88 Consider the following hierarchy of exceptions: 76 89 \begin{center} 77 \input{exception Hierarchy}90 \input{exception-hierarchy} 78 91 \end{center} 92 79 93 A handler labelled with any given exception can handle exceptions of that 80 94 type or any child type of that exception. The root of the exception hierarchy 81 (here \ lstinline[language=C++]{exception}) acts as a catch-all, leaf types catch single types95 (here \codeC{exception}) acts as a catch-all, leaf types catch single types 82 96 and the exceptions in the middle can be used to catch different groups of 83 97 related exceptions. 84 98 85 99 This system has some notable advantages, such as multiple levels of grouping, 86 the ability for libraries to add new exception types, and the isolation 87 between different sub-hierarchies. This capability had to be adapted for \CFA, which is a 88 non-object-orientated language. 100 the ability for libraries to add new exception types and the isolation 101 between different sub-hierarchies. 102 This design is used in \CFA even though it is not a object-orientated 103 language using different tools to create the hierarchy. 89 104 90 105 % Could I cite the rational for the Python IO exception rework? 91 106 92 107 \paragraph{Completion} 93 After the handler has returned,the entire exception operation has to complete94 and continue executing somewhere . This step is usually simple,108 After the handler has finished the entire exception operation has to complete 109 and continue executing somewhere else. This step is usually simple, 95 110 both logically and in its implementation, as the installation of the handler 96 usually does the preparation. 97 The EHM can return control to different places, 98 where the most common are after the handler definition or after the raise. 111 is usually set up to do most of the work. 112 113 The EHM can return control to many different places, 114 the most common are after the handler definition and after the raise. 99 115 100 116 \paragraph{Communication} 101 For effective exception handling, additional information is usually passed from the raise, 102 where this basic model only communicates the exception's identity. A common 103 methods for communication is putting fields into an exception and 104 allowing a handler to access these fields via an exception instance in the handler's scope. 117 For effective exception handling, additional information is usually passed 118 from the raise to the handler. 119 So far only communication of the exceptions' identity has been covered. 120 A common method is putting fields into the exception instance and giving the 121 handler access to them. 105 122 106 123 \section{Virtuals} 107 Virtual types and casts are not part of an EHM nor are they 108 required for an EHM. But as pointed out, an object-oriented-style hierarchy is an 109 excellent way of organizing exceptions. Hence, a minimal virtual system has been added 110 to \CFA to support hierarchical exceptions. 124 Virtual types and casts are not part of \CFA's EHM nor are they required for 125 any EHM. But \CFA uses a hierarchial system of exceptions and this feature 126 is leveraged to create that. 127 128 % Maybe talk about why the virtual system is so minimal. 129 % Created for but not a part of the exception system. 111 130 112 131 The virtual system supports multiple ``trees" of types. Each tree is 113 132 a simple hierarchy with a single root type. Each type in a tree has exactly 114 one parent -- except for the root type w ithzero parents -- and any133 one parent -- except for the root type which has zero parents -- and any 115 134 number of children. 116 135 Any type that belongs to any of these trees is called a virtual type. … … 118 137 % A type's ancestors are its parent and its parent's ancestors. 119 138 % The root type has no ancestors. 120 % A type's descendents are its children and its children's descendents. 121 122 Every virtual type has a list of virtual members. Children inherit 123 their parent's virtual members but may add new members to it. 124 It is important to note that these are virtual members, not virtual methods of an object type. 125 However, as \CFA has function pointers, they can be used to mimic virtual 126 methods. 139 % A type's decendents are its children and its children's decendents. 140 141 Every virtual type also has a list of virtual members. Children inherit 142 their parent's list of virtual members but may add new members to it. 143 It is important to note that these are virtual members, not virtual methods 144 of object-orientated programming, and can be of any type. 145 However, since \CFA has function pointers and they are allowed, virtual 146 members can be used to mimic virtual methods. 127 147 128 148 Each virtual type has a unique id. 129 Th e unique id for the virtual type and all itsvirtual members are combined130 into a virtual -table type. Each virtual type has a pointer to a virtual table149 This unique id and all the virtual members are combined 150 into a virtual table type. Each virtual type has a pointer to a virtual table 131 151 as a hidden field. 132 152 133 Up to this point, a virtual system is similar to ones found in object-oriented134 languages but thisis where \CFA diverges. Objects encapsulate a153 Up until this point the virtual system is similar to ones found in 154 object-orientated languages but this where \CFA diverges. Objects encapsulate a 135 155 single set of behaviours in each type, universally across the entire program, 136 and indeed all programs that use that type definition. In this sense ,the156 and indeed all programs that use that type definition. In this sense the 137 157 types are ``closed" and cannot be altered. 138 However, \CFA types do not encapsulate any behaviour. Instead, traits are used and 139 types can satisfy a trait, stop satisfying a trait, or satisfy the same 140 trait in a different way depending on the lexical context. In this sense, the types are 141 ``open" as their behaviour can change in different scopes. This capability means it is impossible to pick 142 a single set of functions that represent the type's virtual members. 143 144 Hence, \CFA does not have a single virtual table for a type. A user can define different virtual tables, 145 which are filled in at their declaration and given a name. 146 That name is used as the virtual table, even if it is defined locally 147 inside a function, although lifetime issues must be considered. 148 Specifically, an object of a virtual type is ``bound" to a virtual table instance, which 158 159 In \CFA types do not encapsulate any behaviour. Traits are local and 160 types can begin to statify a trait, stop satifying a trait or satify the same 161 trait in a different way at any lexical location in the program. 162 In this sense they are ``open" as they can change at any time. This means it 163 is implossible to pick a single set of functions that repersent the type's 164 implementation across the program. 165 166 \CFA side-steps this issue by not having a single virtual table for each 167 type. A user can define virtual tables which are filled in at their 168 declaration and given a name. Anywhere that name is visible, even if it was 169 defined locally inside a function (although that means it will not have a 170 static lifetime), it can be used. 171 Specifically, a virtual type is ``bound" to a virtual table which 149 172 sets the virtual members for that object. The virtual members can be accessed 150 173 through the object. … … 160 183 \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be 161 184 a pointer to a virtual type. 162 The cast dynamically checks if the @EXPRESSION@ type is the same or a sub type185 The cast dynamically checks if the @EXPRESSION@ type is the same or a sub-type 163 186 of @TYPE@, and if true, returns a pointer to the 164 187 @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). … … 178 201 \end{cfa} 179 202 The trait is defined over two types, the exception type and the virtual table 180 type. Th ese type should have a one-to-one relationship: each exception type has only one virtual203 type. This should be one-to-one: each exception type has only one virtual 181 204 table type and vice versa. The only assertion in the trait is 182 205 @get_exception_vtable@, which takes a pointer of the exception type and 183 returns a reference to the virtual-table type-instance. 184 206 returns a reference to the virtual table type instance. 207 208 % TODO: This section, and all references to get_exception_vtable, are 209 % out-of-data. Perhaps wait until the update is finished before rewriting it. 185 210 The function @get_exception_vtable@ is actually a constant function. 186 Regardless of the value passed in (including the null pointer) it 187 return s a reference to the virtual-table instance for that type.188 The reason it is a function instead of a constant is t omake type189 annotations easier to write using the exception type rather thanthe190 virtual -table type, which usually has a mangled name because it is an internal component of the EHM.211 Regardless of the value passed in (including the null pointer) it should 212 return a reference to the virtual table instance for that type. 213 The reason it is a function instead of a constant is that it make type 214 annotations easier to write as you can use the exception type instead of the 215 virtual table type; which usually has a mangled name. 191 216 % Also \CFA's trait system handles functions better than constants and doing 192 217 % it this way reduce the amount of boiler plate we need. … … 194 219 % I did have a note about how it is the programmer's responsibility to make 195 220 % sure the function is implemented correctly. But this is true of every 196 % similar system I know of (except A da's I guess) so I took it out.197 198 There are two more exception traits defined as follows:221 % similar system I know of (except Agda's I guess) so I took it out. 222 223 There are two more traits for exceptions defined as follows: 199 224 \begin{cfa} 200 225 trait is_termination_exception( … … 208 233 }; 209 234 \end{cfa} 210 These traits ensure a given type and virtual type are an 211 exception type and defines one of the two default handlers. The default handlers 212 a re used in the main exception-handling operations anddiscussed in detail in \VRef{s:ExceptionHandling}.213 214 However, all three of these traits are tricky to use directly.235 Both traits ensure a pair of types are an exception type and its virtual table 236 and defines one of the two default handlers. The default handlers are used 237 as fallbacks and are discussed in detail in \VRef{s:ExceptionHandling}. 238 239 However, all three of these traits can be tricky to use directly. 215 240 While there is a bit of repetition required, 216 the largest issue is that the virtual -table type is mangled and not in a user217 facing way. So th ree macros are provided to wrap these traits218 tosimplify referring to the names:241 the largest issue is that the virtual table type is mangled and not in a user 242 facing way. So these three macros are provided to wrap these traits to 243 simplify referring to the names: 219 244 @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. 220 245 221 These macrostake one or two arguments. The first argument is the name of the222 exception type. The macro passes theunmangled and mangled form to the trait.246 All three take one or two arguments. The first argument is the name of the 247 exception type. The macro passes its unmangled and mangled form to the trait. 223 248 The second (optional) argument is a parenthesized list of polymorphic 224 249 arguments. This argument is only used with polymorphic exceptions and the 225 list is passed to both types.226 In the current set-up, the base name and the polymorphic arguments have to227 matchso these macros can be used without losing flexibility.250 list is be passed to both types. 251 In the current set-up, the two types always have the same polymorphic 252 arguments so these macros can be used without losing flexibility. 228 253 229 254 For example consider a function that is polymorphic over types that have a 230 255 defined arithmetic exception: 231 256 \begin{cfa} 232 forall(Num | @IS_EXCEPTION(Arithmetic, Num)@)257 forall(Num | IS_EXCEPTION(Arithmetic, (Num))) 233 258 void some_math_function(Num & left, Num & right); 234 259 \end{cfa} 235 where the function may raise exception @Arithmetic@ or any of its decedents.236 260 237 261 \section{Exception Handling} 238 262 \label{s:ExceptionHandling} 239 263 \CFA provides two kinds of exception handling: termination and resumption. 240 These twin mechanisms are the core of the \CFA EHM and 241 multiple features are provided to support them. 242 This section covers the general patterns shared by the two kinds of exceptions and 243 then covers the individual detail operations. 244 245 Both mechanisms follow the same set of steps to do their operations. Both 246 start with the user performing an exception raise. 247 Then there is the handler search. If one is found, than the exception 248 is caught and the handler is run. When the handler returns, control returns to an 249 location appropriate for each kind of exception. 250 251 \begin{sloppypar} 252 If the search fails, an appropriate default handler, @defaultTermiationHandler@ 253 or @defaultResumptionHandler@, is run and control returns to the 254 appropriate location. 255 \end{sloppypar} 264 These twin operations are the core of \CFA's exception handling mechanism. 265 This section will cover the general patterns shared by the two operations and 266 then go on to cover the details each individual operation. 267 268 Both operations follow the same set of steps. 269 Both start with the user preforming a raise on an exception. 270 Then the exception propogates up the stack. 271 If a handler is found the exception is caught and the handler is run. 272 After that control returns to normal execution. 273 If the search fails a default handler is run and then control 274 returns to normal execution after the raise. 275 276 This general description covers what the two kinds have in common. 277 Differences include how propogation is preformed, where exception continues 278 after an exception is caught and handled and which default handler is run. 256 279 257 280 \subsection{Termination} 258 281 \label{s:Termination} 259 Termination handling is familiarand used in most programming282 Termination handling is the familiar kind and used in most programming 260 283 languages with exception handling. 261 It is a dynamic, non-local goto. The raise starts searching, and if matched and handled, the stack is 262 unwound and control (usually) continues in the function on 263 the call stack containing the handler. Terminate is commonly used for an error where recovery 264 is impossible in the function performing the raise. 284 It is dynamic, non-local goto. If the raised exception is matched and 285 handled the stack is unwound and control will (usually) continue the function 286 on the call stack that defined the handler. 287 Termination is commonly used when an error has occurred and recovery is 288 impossible locally. 265 289 266 290 % (usually) Control can continue in the current function but then a different … … 272 296 \end{cfa} 273 297 The expression must return a reference to a termination exception, where the 274 termination exception is any type that satisfies trait 275 @is_termination_exception@ at the call site. Through \CFA's trait system, the 276 trait functions are implicitly passed into the hidden throw code and available 277 to the exception system while handling the exception. A new 278 @defaultTerminationHandler@ can be defined in any scope to change the throw's 279 unhandled behaviour (see below). 280 281 The throw must copy the provided exception into managed memory because the stack is unwounded. 282 The lifetime of the exception copy is managed by the exception runtime. 283 It is the user's responsibility to ensure the original exception is cleaned up, where allocating it on the unwound stack is sufficient. 284 285 The exception search walks the stack matching with the copied exception. 298 termination exception is any type that satisfies the trait 299 @is_termination_exception@ at the call site. 300 Through \CFA's trait system the trait functions are implicity passed into the 301 throw code and the EHM. 302 A new @defaultTerminationHandler@ can be defined in any scope to 303 change the throw's behavior (see below). 304 305 The throw will copy the provided exception into managed memory to ensure 306 the exception is not destroyed if the stack is unwound. 307 It is the user's responsibility to ensure the original exception is cleaned 308 up wheither the stack is unwound or not. Allocating it on the stack is 309 usually sufficient. 310 311 Then propogation starts with the search. \CFA uses a ``first match" rule so 312 matching is preformed with the copied exception as the search continues. 286 313 It starts from the throwing function and proceeds to the base of the stack, 287 314 from callee to caller. 288 At each stack frame, a check is made for termination handlers defined by the315 At each stack frame, a check is made for resumption handlers defined by the 289 316 @catch@ clauses of a @try@ statement. 290 317 \begin{cfa} 291 318 try { 292 319 GUARDED_BLOCK 293 } catch (EXCEPTION_TYPE$\(_1\)$ [*NAME$\(_1\)$]) {320 } catch (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) { 294 321 HANDLER_BLOCK$\(_1\)$ 295 } catch (EXCEPTION_TYPE$\(_2\)$ [*NAME$\(_2\)$]) {322 } catch (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) { 296 323 HANDLER_BLOCK$\(_2\)$ 297 324 } 298 325 \end{cfa} 299 When viewed on its own, a @try@ statement with @catch@ clauses simply executes the statements in 300 the @GUARDED_BLOCK@, and when those are finished, the try statement finishes. 301 302 However, while the guarded statements are being executed, including any invoked 303 functions, a termination exception may be thrown. If that exception is not handled by a try 304 statement further up the stack, the handlers following the try block are now 305 searched for a matching termination exception-type from top to bottom. 306 307 Exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is 308 the same or a descendant type of the exception types in the @catch@ clauses. If 309 it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is 326 When viewed on its own, a try statement will simply execute the statements 327 in @GUARDED_BLOCK@ and when those are finished the try statement finishes. 328 329 However, while the guarded statements are being executed, including any 330 invoked functions, all the handlers in the statement are now on the search 331 path. If a termination exception is thrown and not handled further up the 332 stack they will be matched against the exception. 333 334 Exception matching checks the handler in each catch clause in the order 335 they appear, top to bottom. If the representation of the thrown exception type 336 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ 337 (if provided) is 310 338 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ 311 339 are executed. If control reaches the end of the handler, the exception is 312 freed and control continues after the @try@statement.313 314 If no termination handler is found during the search , the default termination315 handler visible at the raise is called. Through \CFA's trait-system the best 316 default-handler match at the throw sight is used. This function is 317 passed the copied exception given to the raise. After the default handler is 318 run, control continues after the @throw@statement.319 320 There is a global @defaultTerminationHandler@ function that that is polymorphic321 over all exception types allowing new default handlers to be defined for 322 d ifferent exception types and so different exception types can have different323 default handlers. The global default termination-handler performs a 324 cancellation \see{\VRef{s:Cancellation}} on the current stack with the copied 325 exception.340 freed and control continues after the try statement. 341 342 If no termination handler is found during the search then the default handler 343 (@defaultTerminationHandler@) is run. 344 Through \CFA's trait system the best match at the throw sight will be used. 345 This function is run and is passed the copied exception. After the default 346 handler is run control continues after the throw statement. 347 348 There is a global @defaultTerminationHandler@ that is polymorphic over all 349 exception types. Since it is so general a more specific handler can be 350 defined and will be used for those types, effectively overriding the handler 351 for particular exception type. 352 The global default termination handler performs a cancellation 353 \see{\VRef{s:Cancellation}} on the current stack with the copied exception. 326 354 327 355 \subsection{Resumption} 328 356 \label{s:Resumption} 329 Resumption exception-handling is a less common counterpart to termination but is 330 just as old~\cite{Goodenough75} and is simpler to understand. 331 It is a dynamic, non-local function call (like Lisp). If the throw is successful, a 332 closure is taken from up the stack and executed, after which the throwing 333 function continues executing. 334 Resumption is used when an error occurred, and if the error is repaired, 357 358 Resumption exception handling is less common than termination but is 359 just as old~\cite{Goodenough75} and is simpler in many ways. 360 It is a dynamic, non-local function call. If the raised exception is 361 matched a closure will be taken from up the stack and executed, 362 after which the raising function will continue executing. 363 These are most often used when an error occurred and if the error is repaired 335 364 then the function can continue. 336 365 337 An alternative approach is explicitly passing fixup functions with local338 closures up the stack to be called when an error occurs. However, fixup339 functions significantly expand the parameters list of functions, even when the340 fixup function is not used by a function but must be passed to other called341 functions.342 343 366 A resumption raise is started with the @throwResume@ statement: 344 367 \begin{cfa} 345 368 throwResume EXPRESSION; 346 369 \end{cfa} 347 Like termination, the expression must return a reference to a resumption 348 exception, where the resumption exception is any type that satisfies the trait 349 @is_termination_exception@ at the call site. 350 The assertions for this trait are available to 370 It works much the same way as the termination throw. 371 The expression must return a reference to a resumption exception, 372 where the resumption exception is any type that satisfies the trait 373 @is_resumption_exception@ at the call site. 374 The assertions from this trait are available to 351 375 the exception system while handling the exception. 352 376 353 At run time, no exception copy is made, as the stack is not unwound. Hence, the exception and354 any values on the stack remain in scope while the resumption is handled. 355 356 The exception searches walks the stack matching with the provided exception. 357 It starts from the resuming function and proceeds to the base of the stack, 358 from callee to caller.377 At run-time, no exception copy is made. 378 As the stack is not unwound the exception and 379 any values on the stack will remain in scope while the resumption is handled. 380 381 The EHM then begins propogation. The search starts from the raise in the 382 resuming function and proceeds to the base of the stack, from callee to caller. 359 383 At each stack frame, a check is made for resumption handlers defined by the 360 384 @catchResume@ clauses of a @try@ statement. … … 362 386 try { 363 387 GUARDED_BLOCK 364 } catchResume (EXCEPTION_TYPE$\(_1\)$ [*NAME$\(_1\)$]) {388 } catchResume (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) { 365 389 HANDLER_BLOCK$\(_1\)$ 366 } catchResume (EXCEPTION_TYPE$\(_2\)$ [*NAME$\(_2\)$]) {390 } catchResume (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) { 367 391 HANDLER_BLOCK$\(_2\)$ 368 392 } 369 393 \end{cfa} 370 Termination and resumption handlers may be intermixed in a @try@ 371 statement but the kind of throw must match with kind of handler for it to be 372 considered as a possible match. 373 Like termination, when viewed on its own, a @try@ statement with 374 @catchResume@ clauses simply executes the statements in the @GUARDED_BLOCK@, 375 and when those are finished, the try statement finishes. 376 377 However, while the guarded statements are being executed, including any invoked 378 functions, a resumption exception may be thrown. If that exception is not handled by a try 379 statement further up the stack, the handlers following the try block are now 380 searched for a matching resumption exception-type from top to bottom. 381 382 Like termination, exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is 383 the same or a descendant type of the exception types in the @catchResume@ clauses. If 384 it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is 385 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ 386 are executed. If control reaches the end of the handler, the exception is 387 freed and control continues after the @throwResume@ statement. 388 389 Like termination, if no resumption handler is found during the search, the 390 default resumption handler visible at the raise is called, which is the best 391 match at the according to \CFA's overloading rules. This function is passed the 392 exception given to the raise. After the default handler is run, execution 393 continues after the @throwResume@ statement. 394 395 There is a global @defaultResumptionHandler@ that is polymorphic over all 396 resumption and preforms a termination throw on the exception. 397 The @defaultTerminationHandler@ for that throw is matched at the original 398 throw statement (the resumption @throwResume@) and it can be customized by 394 % I wonder if there would be some good central place for this. 395 Note that termination handlers and resumption handlers may be used together 396 in a single try statement, intermixing @catch@ and @catchResume@ freely. 397 Each type of handler will only interact with exceptions from the matching 398 type of raise. 399 When a try statement is executed it simply executes the statements in the 400 @GUARDED_BLOCK@ and then finishes. 401 402 However, while the guarded statements are being executed, including any 403 invoked functions, all the handlers in the statement are now on the search 404 path. If a resumption exception is reported and not handled further up the 405 stack they will be matched against the exception. 406 407 Exception matching checks the handler in each catch clause in the order 408 they appear, top to bottom. If the representation of the thrown exception type 409 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ 410 (if provided) is bound to a pointer to the exception and the statements in 411 @HANDLER_BLOCK@$_i$ are executed. 412 If control reaches the end of the handler, execution continues after the 413 the raise statement that raised the handled exception. 414 415 Like termination, if no resumption handler is found, the default handler 416 visible at the throw statement is called. It will use the best match at the 417 call sight according to \CFA's overloading rules. The default handler is 418 passed the exception given to the throw. When the default handler finishes 419 execution continues after the raise statement. 420 421 There is a global @defaultResumptionHandler@ is polymorphic over all 422 termination exceptions and preforms a termination throw on the exception. 423 The @defaultTerminationHandler@ for that raise is matched at the original 424 raise statement (the resumption @throwResume@) and it can be customized by 399 425 introducing a new or better match as well. 400 426 401 \subs ection{Resumption Marking}427 \subsubsection{Resumption Marking} 402 428 A key difference between resumption and termination is that resumption does 403 not unwind the stack. A side effect is that when a handler is matched404 and run it s try block (the guarded statements) and every try statement429 not unwind the stack. A side effect that is that when a handler is matched 430 and run it's try block (the guarded statements) and every try statement 405 431 searched before it are still on the stack. This can lead to the recursive 406 432 resumption problem. … … 416 442 } 417 443 \end{cfa} 418 When this code is executed the guarded @throwResume@ startsa419 search and match es the handler in the @catchResume@ clause. The handler is420 call ed and placed on the stack on top of the try-block. The second throw in the handler421 searches the same try block and callsanother instance of the444 When this code is executed the guarded @throwResume@ will throw, start a 445 search and match the handler in the @catchResume@ clause. This will be 446 call and placed on the stack on top of the try-block. The second throw then 447 throws and will search the same try block and put call another instance of the 422 448 same handler leading to an infinite loop. 423 449 424 While this situation is trivial and easy to avoid,much more complex cycles450 This situation is trivial and easy to avoid, but much more complex cycles 425 451 can form with multiple handlers and different exception types. 426 452 427 To prevent this case, examined try statements on the stack are marked, so that 428 subsequent resumption searches skip over them and continue with the next unmarked section 429 of the stack. 430 Unmarking occurs when that exception is handled 431 or the search completes without finding a handler. 432 433 % This might need a diagram. But it is an important part of the justification 434 % of the design of the traversal order. 453 To prevent all of these cases we mark try statements on the stack. 454 A try statement is marked when a match check is preformed with it and an 455 exception. The statement will be unmarked when the handling of that exception 456 is completed or the search completes without finding a handler. 457 While a try statement is marked its handlers are never matched, effectify 458 skipping over it to the next try statement. 435 459 436 460 \begin{center} 437 %\begin{verbatim} 438 % throwResume2 ----------. 439 % | | 440 % generated from handler | 441 % | | 442 % handler | 443 % | | 444 % throwResume1 -----. : 445 % | | : 446 % try | : search skip 447 % | | : 448 % catchResume <----' : 449 % | | 450 %\end{verbatim} 451 \input{stackMarking} 461 \input{stack-marking} 452 462 \end{center} 453 463 454 The resulting search can be understood by thinking about what is searched for455 termination. When a throw happens in a handler, a termination handler 456 skips everythingfrom the original throw to the original catch because that457 part of the stack is unwound. A resumption handler skips the same458 section of stack because it is marked. 459 A throw in a resumption default-handler performs the same search as the original 460 @throwResume@ because for resumption nothing has been unwound.461 462 The symmetry between resumption masking and termination searching is why this pattern was picked. Other patterns,463 such as marking just the handlers that caught, also work but the 464 symmetry seems to match programmer intuition.464 These rules mirror what happens with termination. 465 When a termination throw happens in a handler the search will not look at 466 any handlers from the original throw to the original catch because that 467 part of the stack has been unwound. 468 A resumption raise in the same situation wants to search the entire stack, 469 but it will not try to match the exception with try statements in the section 470 that would have been unwound as they are marked. 471 472 The symmetry between resumption termination is why this pattern was picked. 473 Other patterns, such as marking just the handlers that caught, also work but 474 lack the symmetry means there are less rules to remember. 465 475 466 476 \section{Conditional Catch} 467 Both termination and resumption handler -clauses can be given an additional468 condition to further control which exceptions is handled:469 \begin{cfa} 470 catch (EXCEPTION_TYPE [* NAME] @; CONDITION@)477 Both termination and resumption handler clauses can be given an additional 478 condition to further control which exceptions they handle: 479 \begin{cfa} 480 catch (EXCEPTION_TYPE * [NAME] ; CONDITION) 471 481 \end{cfa} 472 482 First, the same semantics is used to match the exception type. Second, if the 473 483 exception matches, @CONDITION@ is executed. The condition expression may 474 reference all names in the scopeof the try block and @NAME@484 reference all names in scope at the beginning of the try block and @NAME@ 475 485 introduced in the handler clause. If the condition is true, then the handler 476 486 matches. Otherwise, the exception search continues as if the exception type 477 487 did not match. 478 488 479 Conditional catch allows fine-gain matching based on object values as well as exception types. 480 For example, assume the exception hierarchy @OpenFailure@ $\rightarrow$ @CreateFailure@ and these exceptions are raised by function @open@. 481 \begin{cfa} 482 try { 483 f1 = open( ... ); // open raises CreateFailure/OpenFailure 484 f2 = open( ... ); // with the associate file 489 The condition matching allows finer matching by allowing the match to check 490 more kinds of information than just the exception type. 491 \begin{cfa} 492 try { 493 handle1 = open( f1, ... ); 494 handle2 = open( f2, ... ); 495 handle3 = open( f3, ... ); 485 496 ... 486 } catch( CreateFailure * f ; @fd( f ) == f1@ ) { 487 // only handle IO failure for f1 488 } catch( OpenFailure * f ; @fd( f ) == f2@ ) { 489 // only handle IO failure for f2 490 } 491 \end{cfa} 492 Here, matching is very precise on the I/O exception and particular file with an open problem. 493 This capability cannot be easily mimiced within the handler. 494 \begin{cfa} 495 try { 496 f1 = open( ... ); 497 f2 = open( ... ); 498 ... 499 } catch( CreateFailure * f ) { 500 if ( @fd( f ) == f1@ ) ... else // reraise 501 } catch( OpenFailure * f ) { 502 if ( @fd( f ) == f2@ ) ... else // reraise 503 } 504 \end{cfa} 505 When an exception @CreateFailure@ is raised, the first handler catches the 506 derived exception and reraises it if the object is inappropriate. The reraise 507 immediately terminates the current guarded block, which precludes the handler 508 for the base exception @OpenFailure@ from consideration for object 509 @f2@. Therefore, the ``catch first, then reraise'' approach is an incomplete 510 substitute for conditional catch. 511 512 \section{Reraise} 513 \label{s:Rethrowing} 514 \colour{red}{From Andrew: I recommend we talk about why the language doesn't 515 have rethrows/reraises instead.} 516 497 } catch( IOFailure * f ; fd( f ) == f1 ) { 498 // Only handle IO failure for f1. 499 } catch( IOFailure * f ; fd( f ) == f3 ) { 500 // Only handle IO failure for f3. 501 } 502 // Can't handle a failure relating to f2 here. 503 \end{cfa} 504 In this example the file that experianced the IO error is used to decide 505 which handler should be run, if any at all. 506 507 \begin{comment} 508 % I know I actually haven't got rid of them yet, but I'm going to try 509 % to write it as if I had and see if that makes sense: 510 \section{Reraising} 511 \label{s:Reraising} 517 512 Within the handler block or functions called from the handler block, it is 518 513 possible to reraise the most recently caught exception with @throw@ or … … 533 528 is part of an unwound stack frame. To prevent this problem, a new default 534 529 handler is generated that does a program-level abort. 535 \PAB{I don't see how this is different from the normal throw/throwResume.} 530 \end{comment} 531 532 \subsection{Comparison with Reraising} 533 A more popular way to allow handlers to match in more detail is to reraise 534 the exception after it has been caught if it could not be handled here. 535 On the surface these two features seem interchangable. 536 537 If we used @throw;@ to start a termination reraise then these two statements 538 would have the same behaviour: 539 \begin{cfa} 540 try { 541 do_work_may_throw(); 542 } catch(exception_t * exc ; can_handle(exc)) { 543 handle(exc); 544 } 545 \end{cfa} 546 547 \begin{cfa} 548 try { 549 do_work_may_throw(); 550 } catch(exception_t * exc) { 551 if (can_handle(exc)) { 552 handle(exc); 553 } else { 554 throw; 555 } 556 } 557 \end{cfa} 558 If there are further handlers after this handler only the first version will 559 check them. If multiple handlers on a single try block could handle the same 560 exception the translations get more complex but they are equivilantly 561 powerful. 562 563 Until stack unwinding comes into the picture. In termination handling, a 564 conditional catch happens before the stack is unwound, but a reraise happens 565 afterwards. Normally this might only cause you to loose some debug 566 information you could get from a stack trace (and that can be side stepped 567 entirely by collecting information during the unwind). But for \CFA there is 568 another issue, if the exception isn't handled the default handler should be 569 run at the site of the original raise. 570 571 There are two problems with this: the site of the original raise doesn't 572 exist anymore and the default handler might not exist anymore. The site will 573 always be removed as part of the unwinding, often with the entirety of the 574 function it was in. The default handler could be a stack allocated nested 575 function removed during the unwind. 576 577 This means actually trying to pretend the catch didn't happening, continuing 578 the original raise instead of starting a new one, is infeasible. 579 That is the expected behaviour for most languages and we can't replicate 580 that behaviour. 536 581 537 582 \section{Finally Clauses} 538 Finally clauses are used to perform unconditional clean-up when leaving a 539 scope and appear at the end of a try statement after any catch clauses: 583 \label{s:FinallyClauses} 584 Finally clauses are used to preform unconditional clean-up when leaving a 585 scope and are placed at the end of a try statement after any handler clauses: 540 586 \begin{cfa} 541 587 try { … … 548 594 The @FINALLY_BLOCK@ is executed when the try statement is removed from the 549 595 stack, including when the @GUARDED_BLOCK@ finishes, any termination handler 550 finishes ,or during an unwind.596 finishes or during an unwind. 551 597 The only time the block is not executed is if the program is exited before 552 598 the stack is unwound. 553 599 554 600 Execution of the finally block should always finish, meaning control runs off 555 the end of the block. This requirement ensures execution always continues as if the 556 finally clause is not present, \ie @finally@ is for cleanup not changing control 557 flow. Because of this requirement, local control flow out of the finally block 601 the end of the block. This requirement ensures control always continues as if 602 the finally clause is not present, \ie finally is for cleanup not changing 603 control flow. 604 Because of this requirement, local control flow out of the finally block 558 605 is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or 559 606 @return@ that causes control to leave the finally block. Other ways to leave 560 607 the finally block, such as a long jump or termination are much harder to check, 561 and at best requir e additional run-time overhead, and so are608 and at best requiring additional run-time overhead, and so are only 562 609 discouraged. 563 610 564 Not all languages with exceptionshave finally clauses. Notably \Cpp does565 without it as des tructors serve a similar role. Although destructors and566 finally clauses can be used in many of the same areas ,they have their own611 Not all languages with unwinding have finally clauses. Notably \Cpp does 612 without it as descructors serve a similar role. Although destructors and 613 finally clauses can be used in many of the same areas they have their own 567 614 use cases like top-level functions and lambda functions with closures. 568 615 Destructors take a bit more work to set up but are much easier to reuse while 569 finally clauses are good for one-off situations and can easily include local information. 616 finally clauses are good for one-off uses and 617 can easily include local information. 570 618 571 619 \section{Cancellation} 572 620 \label{s:Cancellation} 573 Cancellation is a stack-level abort, which can be thought of as a n574 uncatchable termination. It unwinds the entire stack, and when575 possible ,forwards the cancellation exception to a different stack.621 Cancellation is a stack-level abort, which can be thought of as as an 622 uncatchable termination. It unwinds the entire current stack, and if 623 possible forwards the cancellation exception to a different stack. 576 624 577 625 Cancellation is not an exception operation like termination or resumption. 578 626 There is no special statement for starting a cancellation; instead the standard 579 627 library function @cancel_stack@ is called passing an exception. Unlike a 580 throw, this exception is not used in matching only to pass information about628 raise, this exception is not used in matching only to pass information about 581 629 the cause of the cancellation. 582 (This semanticsalso means matching cannot fail so there is no default handler.)583 584 After @cancel_stack@ is called , the exception is copied into the EHM's585 memoryand the current stack is630 (This also means matching cannot fail so there is no default handler.) 631 632 After @cancel_stack@ is called the exception is copied into the EHM's memory 633 and the current stack is 586 634 unwound. After that it depends one which stack is being cancelled. 587 635 \begin{description} 588 636 \item[Main Stack:] 589 637 The main stack is the one used by the program main at the start of execution, 590 and is the only stack in a sequential program. Even in a concurrent program, 591 the main stack is often used as the environment to start the concurrent threads. 592 Hence, when the main stack is cancelled there is nowhere else in the program 593 to go. Hence, after the main stack is unwound, there is a program-level abort. 638 and is the only stack in a sequential program. 639 After the main stack is unwound there is a program-level abort. 640 641 There are two reasons for this. The first is that it obviously had to do this 642 in a sequential program as there is nothing else to notify and the simplicity 643 of keeping the same behaviour in sequential and concurrent programs is good. 644 Also, even in concurrent programs there is no stack that an innate connection 645 to, so it would have be explicitly managed. 594 646 595 647 \item[Thread Stack:] 596 A thread stack is created for a \CFA @thread@ object or object that satisfies the 597 @is_thread@ trait. A thread only has two points of communication that must 598 happen: start and join. A thread must be running to perform a 599 cancellation (a thread cannot cancel another thread). Therefore, a cancellation must 600 occur after start and before join, so join is used 601 for cancellation communication. 602 After the stack is unwound, the thread halts and waits for 603 another thread to join with it. The joining thread checks for a cancellation, 604 and if present, resumes exception @ThreadCancelled@. 605 606 \begin{sloppypar} 607 There is a subtle difference between the explicit join (@join@ function) and 608 implicit join (from a @thread@'s destructor call). The explicit join takes the default 609 handler (@defaultResumptionHandler@) from its calling context, which is used if 610 the exception is not caught. The implicit join does a program abort instead. 611 \end{sloppypar} 612 613 \PAB{uC++ does not have these issues, but catch(...) is not working.} 614 \begin{lstlisting}[language=uC++] 615 #include <iostream> 616 using namespace std; 617 618 struct Cl { 619 ~Cl() { cout << "C" << endl; } 620 }; 621 _Coroutine C { 622 void main() { 623 Cl c; 624 try { 625 cancel(); 626 } catch( ... ) { 627 cout << "..." << endl; 628 } _Finally { 629 cout << "F" << endl; 630 } 631 } 632 public: 633 void mem() { resume(); } 634 }; 635 _Task T { 636 void main() { 637 Cl c; 638 try { 639 cancel(); 640 } catch( ... ) { 641 cout << "..." << endl; 642 } _Finally { 643 cout << "F" << endl; 644 } 645 } 646 }; 647 int main() { 648 C c; 649 cout << "here1" << endl; 650 c.mem(); 651 cout << "here2" << endl; 652 { 653 T t; 654 } 655 cout << "here3" << endl; 656 } 657 \end{lstlisting} 658 659 \PAB{This discussion should be its own section.} 660 This semantics is for safety. If an unwind is triggered while another unwind 661 is underway only one of them can proceed as they both want to ``consume" the 662 stack. Letting both try to proceed leads to very undefined behaviour. 663 Both termination and cancellation involve unwinding and, since the default 664 @defaultResumptionHandler@ preforms a termination that could more easily 665 happen in an implicate join inside a destructor. So there is an error message 666 and an abort instead. 667 668 \todo{Perhaps have a more general disucssion of unwind collisions before 669 this point.} 670 671 The recommended way to avoid the abort is to handle the initial resumption 672 from the implicate join. If required you may put an explicate join inside a 673 finally clause to disable the check and use the local 674 @defaultResumptionHandler@ instead. 675 676 \item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object 677 or object that satisfies the @is_coroutine@ trait. A coroutine only knows of 678 two other coroutines, its starter and its last resumer. Of the two the last 679 resumer has the tightest coupling to the coroutine it activated and the most 680 up-to-date information. 681 682 Hence, cancellation of the active coroutine is forwarded to the last resumer 683 after the stack is unwound. When the resumer restarts, it resumes exception 684 @CoroutineCancelled@, which is polymorphic over the coroutine type and has a 685 pointer to the cancelled coroutine. 686 687 The resume function also has an assertion that the @defaultResumptionHandler@ 688 for the exception. So it will use the default handler like a regular throw. 648 A thread stack is created for a \CFA @thread@ object or object that satisfies 649 the @is_thread@ trait. 650 After a thread stack is unwound there exception is stored until another 651 thread attempts to join with it. Then the exception @ThreadCancelled@, 652 which stores a reference to the thread and to the exception passed to the 653 cancellation, is reported from the join. 654 There is one difference between an explicit join (with the @join@ function) 655 and an implicit join (from a destructor call). The explicit join takes the 656 default handler (@defaultResumptionHandler@) from its calling context while 657 the implicit join provides its own which does a program abort if the 658 @ThreadCancelled@ exception cannot be handled. 659 660 Communication is done at join because a thread only has to have to points of 661 communication with other threads: start and join. 662 Since a thread must be running to perform a cancellation (and cannot be 663 cancelled from another stack), the cancellation must be after start and 664 before the join. So join is the one that we will use. 665 666 % TODO: Find somewhere to discuss unwind collisions. 667 The difference between the explicit and implicit join is for safety and 668 debugging. It helps prevent unwinding collisions by avoiding throwing from 669 a destructor and prevents cascading the error across multiple threads if 670 the user is not equipped to deal with it. 671 Also you can always add an explicit join if that is the desired behaviour. 672 673 \item[Coroutine Stack:] 674 A coroutine stack is created for a @coroutine@ object or object that 675 satisfies the @is_coroutine@ trait. 676 After a coroutine stack is unwound control returns to the resume function 677 that most recently resumed it. The resume statement reports a 678 @CoroutineCancelled@ exception, which contains a references to the cancelled 679 coroutine and the exception used to cancel it. 680 The resume function also takes the @defaultResumptionHandler@ from the 681 caller's context and passes it to the internal report. 682 683 A coroutine knows of two other coroutines, its starter and its last resumer. 684 The starter has a much more distant connection while the last resumer just 685 (in terms of coroutine state) called resume on this coroutine, so the message 686 is passed to the latter. 689 687 \end{description} 690 691 \PAB{You should have more test programs that compare \CFA EHM to uC++ EHM.} -
doc/theses/andrew_beach_MMath/uw-ethesis.tex
rddd473f r0583b47b 74 74 % ====================================================================== 75 75 % D O C U M E N T P R E A M B L E 76 % Specify the document class, default style attributes, page dimensions, etc. 77 % For hyperlinked PDF, suitable for viewing on a computer, use this: 78 \documentclass[letterpaper,12pt,titlepage,oneside,final]{book} 79 80 % For PDF, suitable for double-sided printing, change the PrintVersion 81 % variable below to "true" and use this \documentclass line instead of the 82 % one above: 83 %\documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book} 84 85 \usepackage{etoolbox} 76 \RequirePackage{etoolbox} 77 78 % Control if this for print (set true) or will stay digital (default). 79 % Print is two sided, digital uses more colours. 80 \newtoggle{printversion} 81 %\toggletrue{printversion} 82 83 \iftoggle{printversion}{% 84 \documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book} 85 }{% 86 \documentclass[letterpaper,12pt,titlepage,oneside,final]{book} 87 } 86 88 87 89 % Some LaTeX commands I define for my own nomenclature. … … 94 96 % Anything defined here may be redefined by packages added below... 95 97 96 % This package allows if-then-else control structures. 97 \usepackage{ifthen} 98 \newboolean{PrintVersion} 99 \setboolean{PrintVersion}{false} 100 % CHANGE THIS VALUE TO "true" as necessary, to improve printed results for 101 % hard copies by overriding some options of the hyperref package, called below. 102 103 %\usepackage{nomencl} % For a nomenclature (optional; available from ctan.org) 98 % For a nomenclature (optional; available from ctan.org) 99 %\usepackage{nomencl} 104 100 % Lots of math symbols and environments 105 101 \usepackage{amsmath,amssymb,amstext} 106 % For including graphics N.B. pdftex graphics driver 107 %\usepackage[pdftex]{graphicx} 102 % For including graphics (must match graphics driver) 108 103 \usepackage{epic,eepic} 109 104 \usepackage{graphicx} … … 113 108 \usepackage{todonotes} 114 109 115 116 110 % Hyperlinks make it very easy to navigate an electronic document. 117 111 % In addition, this is where you should specify the thesis title and author as … … 119 113 % Use the "hyperref" package 120 114 % N.B. HYPERREF MUST BE THE LAST PACKAGE LOADED; ADD ADDITIONAL PKGS ABOVE 121 %\usepackage[pdftex,pagebackref=true]{hyperref} % with basic options 122 \usepackage[pagebackref=true]{hyperref} % with basic options 123 %\usepackage[pdftex,pagebackref=true]{hyperref} 115 \usepackage[pagebackref=true]{hyperref} 124 116 % N.B. pagebackref=true provides links back from the References to the body 125 117 % text. This can cause trouble for printing. … … 131 123 pdffitwindow=false, % window fit to page when opened 132 124 pdfstartview={FitH}, % fits the width of the page to the window 133 % pdftitle={uWaterloo\ LaTeX\ Thesis\ Template}, % title: CHANGE THIS TEXT!134 % pdfauthor={Author}, % author: CHANGE THIS TEXT! and uncomment this line135 % pdfsubject={Subject}, % subject: CHANGE THIS TEXT! and uncomment this line136 % pdfkeywords={keyword1} {key2} {key3}, % optional list of keywords137 125 pdfnewwindow=true, % links in new window 138 126 colorlinks=true, % false: boxed links; true: colored links 139 linkcolor=blue, % color of internal links140 citecolor=green, % color of links to bibliography141 filecolor=magenta, % color of file links142 urlcolor=cyan % color of external links143 127 } 144 % for improved print quality, change some hyperref options 145 \ifthenelse{\boolean{PrintVersion}}{ 146 \hypersetup{ % override some previously defined hyperref options 147 % colorlinks,% 148 citecolor=black,% 149 filecolor=black,% 150 linkcolor=black,% 151 urlcolor=black} 152 }{} % end of ifthenelse (no else) 128 \iftoggle{printversion}{ 129 \hypersetup{ 130 citecolor=black, % colour of links to bibliography 131 filecolor=black, % colour of file links 132 linkcolor=black, % colour of internal links 133 urlcolor=black, % colour of external links 134 } 135 }{ % Digital Version 136 \hypersetup{ 137 citecolor=green, 138 filecolor=magenta, 139 linkcolor=blue, 140 urlcolor=cyan, 141 } 142 } 143 144 \hypersetup{ 145 pdftitle={Exception Handling in Cforall}, 146 pdfauthor={Andrew James Beach}, 147 pdfsubject={Computer Science}, 148 pdfkeywords={programming languages} {exceptions} 149 {language design} {language implementation}, 150 } 153 151 154 152 % Exception to the rule of hyperref being the last add-on package … … 220 218 \pdfstringdefDisableCommands{\def\Cpp{C++}} 221 219 220 % Wrappers for inline code snippits. 221 \newrobustcmd*\codeCFA[1]{\lstinline[language=CFA]{#1}} 222 \newrobustcmd*\codeC[1]{\lstinline[language=C]{#1}} 223 \newrobustcmd*\codeCpp[1]{\lstinline[language=C++]{#1}} 224 \newrobustcmd*\codePy[1]{\lstinline[language=Python]{#1}} 225 222 226 % Colour text, formatted in LaTeX style instead of TeX style. 223 227 \newcommand*\colour[2]{{\color{#1}#2}}
Note: See TracChangeset
for help on using the changeset viewer.
