[4706098c] | 1 | \chapter{Exception Features} |
---|
| 2 | |
---|
| 3 | This chapter covers the design and user interface of the \CFA |
---|
| 4 | exception-handling mechanism. |
---|
| 5 | |
---|
| 6 | \section{Virtuals} |
---|
| 7 | Virtual types and casts are not required for a basic exception-system but are |
---|
| 8 | useful for advanced exception features. However, \CFA is not object-oriented so |
---|
[1c1c180] | 9 | there is no obvious concept of virtuals. Hence, to create advanced exception |
---|
[4706098c] | 10 | features for this work, I needed to designed and implemented a virtual-like |
---|
| 11 | system for \CFA. |
---|
| 12 | |
---|
| 13 | Object-oriented languages often organized exceptions into a simple hierarchy, |
---|
| 14 | \eg Java. |
---|
| 15 | \begin{center} |
---|
| 16 | \setlength{\unitlength}{4000sp}% |
---|
| 17 | \begin{picture}(1605,612)(2011,-1951) |
---|
| 18 | \put(2100,-1411){\vector(1, 0){225}} |
---|
| 19 | \put(3450,-1411){\vector(1, 0){225}} |
---|
| 20 | \put(3550,-1411){\line(0,-1){225}} |
---|
| 21 | \put(3550,-1636){\vector(1, 0){150}} |
---|
| 22 | \put(3550,-1636){\line(0,-1){225}} |
---|
| 23 | \put(3550,-1861){\vector(1, 0){150}} |
---|
| 24 | \put(2025,-1490){\makebox(0,0)[rb]{\LstBasicStyle{exception}}} |
---|
| 25 | \put(2400,-1460){\makebox(0,0)[lb]{\LstBasicStyle{arithmetic}}} |
---|
| 26 | \put(3750,-1460){\makebox(0,0)[lb]{\LstBasicStyle{underflow}}} |
---|
| 27 | \put(3750,-1690){\makebox(0,0)[lb]{\LstBasicStyle{overflow}}} |
---|
| 28 | \put(3750,-1920){\makebox(0,0)[lb]{\LstBasicStyle{zerodivide}}} |
---|
| 29 | \end{picture}% |
---|
| 30 | \end{center} |
---|
| 31 | The hierarchy provides the ability to handle an exception at different degrees |
---|
[1c1c180] | 32 | of specificity (left to right). Hence, it is possible to catch a more general |
---|
[4706098c] | 33 | exception-type in higher-level code where the implementation details are |
---|
| 34 | unknown, which reduces tight coupling to the lower-level implementation. |
---|
| 35 | Otherwise, low-level code changes require higher-level code changes, \eg, |
---|
| 36 | changing from raising @underflow@ to @overflow@ at the low level means changing |
---|
| 37 | the matching catch at the high level versus catching the general @arithmetic@ |
---|
| 38 | exception. In detail, each virtual type may have a parent and can have any |
---|
| 39 | number of children. A type's descendants are its children and its children's |
---|
| 40 | descendants. A type may not be its own descendant. |
---|
| 41 | |
---|
| 42 | The exception hierarchy allows a handler (@catch@ clause) to match multiple |
---|
| 43 | exceptions, \eg a base-type handler catches both base and derived |
---|
| 44 | exception-types. |
---|
| 45 | \begin{cfa} |
---|
| 46 | try { |
---|
| 47 | ... |
---|
| 48 | } catch(arithmetic &) { |
---|
| 49 | ... // handle arithmetic, underflow, overflow, zerodivide |
---|
| 50 | } |
---|
| 51 | \end{cfa} |
---|
| 52 | Most exception mechanisms perform a linear search of the handlers and select |
---|
| 53 | the first matching handler, so the order of handers is now important because |
---|
| 54 | matching is many to one. |
---|
| 55 | |
---|
| 56 | Each virtual type needs an associated virtual table. A virtual table is a |
---|
| 57 | structure with fields for all the virtual members of a type. A virtual type has |
---|
| 58 | all the virtual members of its parent and can add more. It may also update the |
---|
| 59 | values of the virtual members and often does. |
---|
| 60 | |
---|
| 61 | While much of the virtual infrastructure is created, it is currently only used |
---|
| 62 | internally for exception handling. The only user-level feature is the virtual |
---|
| 63 | cast, which is the same as the \CC \lstinline[language=C++]|dynamic_cast|. |
---|
[7eb6eb5] | 64 | \label{p:VirtualCast} |
---|
[4706098c] | 65 | \begin{cfa} |
---|
[4a36b344] | 66 | (virtual TYPE)EXPRESSION |
---|
[4706098c] | 67 | \end{cfa} |
---|
| 68 | Note, the syntax and semantics matches a C-cast, rather than the unusual \CC |
---|
| 69 | syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be a |
---|
| 70 | pointer to a virtual type. The cast dynamically checks if the @EXPRESSION@ type |
---|
| 71 | is the same or a subtype of @TYPE@, and if true, returns a pointer to the |
---|
| 72 | @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). |
---|
| 73 | |
---|
| 74 | \section{Exception} |
---|
[4a36b344] | 75 | % Leaving until later, hopefully it can talk about actual syntax instead |
---|
| 76 | % of my many strange macros. Syntax aside I will also have to talk about the |
---|
| 77 | % features all exceptions support. |
---|
| 78 | |
---|
[4706098c] | 79 | Exceptions are defined by the trait system; there are a series of traits, and |
---|
[1c1c180] | 80 | if a type satisfies them, then it can be used as an exception. The following |
---|
[4706098c] | 81 | is the base trait all exceptions need to match. |
---|
| 82 | \begin{cfa} |
---|
| 83 | trait is_exception(exceptT &, virtualT &) { |
---|
| 84 | virtualT const & @get_exception_vtable@(exceptT *); |
---|
[02b73ea] | 85 | }; |
---|
[4706098c] | 86 | \end{cfa} |
---|
| 87 | The function takes any pointer, including the null pointer, and returns a |
---|
| 88 | reference to the virtual-table object. Defining this function also establishes |
---|
| 89 | the virtual type and a virtual-table pair to the \CFA type-resolver and |
---|
| 90 | promises @exceptT@ is a virtual type and a child of the base exception-type. |
---|
| 91 | |
---|
[7eb6eb5] | 92 | \PAB{I do not understand this paragraph.} |
---|
[4706098c] | 93 | One odd thing about @get_exception_vtable@ is that it should always be a |
---|
[1c1c180] | 94 | constant function, returning the same value regardless of its argument. A |
---|
[4706098c] | 95 | pointer or reference to the virtual table instance could be used instead, |
---|
| 96 | however using a function has some ease of implementation advantages and allows |
---|
| 97 | for easier disambiguation because the virtual type name (or the address of an |
---|
| 98 | instance that is in scope) can be used instead of the mangled virtual table |
---|
[1c1c180] | 99 | name. Also note the use of the word ``promise'' in the trait |
---|
[4706098c] | 100 | description. Currently, \CFA cannot check to see if either @exceptT@ or |
---|
| 101 | @virtualT@ match the layout requirements. This is considered part of |
---|
| 102 | @get_exception_vtable@'s correct implementation. |
---|
| 103 | |
---|
| 104 | \section{Raise} |
---|
[7eb6eb5] | 105 | \CFA provides two kinds of exception raise: termination |
---|
| 106 | \see{\VRef{s:Termination}} and resumption \see{\VRef{s:Resumption}}, which are |
---|
[4706098c] | 107 | specified with the following traits. |
---|
| 108 | \begin{cfa} |
---|
[02b73ea] | 109 | trait is_termination_exception( |
---|
[4706098c] | 110 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
| 111 | void @defaultTerminationHandler@(exceptT &); |
---|
[02b73ea] | 112 | }; |
---|
[4706098c] | 113 | \end{cfa} |
---|
| 114 | The function is required to allow a termination raise, but is only called if a |
---|
| 115 | termination raise does not find an appropriate handler. |
---|
[02b73ea] | 116 | |
---|
[4706098c] | 117 | Allowing a resumption raise is similar. |
---|
| 118 | \begin{cfa} |
---|
[02b73ea] | 119 | trait is_resumption_exception( |
---|
[4706098c] | 120 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
| 121 | void @defaultResumptionHandler@(exceptT &); |
---|
[02b73ea] | 122 | }; |
---|
[4706098c] | 123 | \end{cfa} |
---|
| 124 | The function is required to allow a resumption raise, but is only called if a |
---|
| 125 | resumption raise does not find an appropriate handler. |
---|
| 126 | |
---|
| 127 | Finally there are three convenience macros for referring to the these traits: |
---|
[1c1c180] | 128 | @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. Each |
---|
[4706098c] | 129 | takes the virtual type's name, and for polymorphic types only, the |
---|
| 130 | parenthesized list of polymorphic arguments. These macros do the name mangling |
---|
| 131 | to get the virtual-table name and provide the arguments to both sides |
---|
[7eb6eb5] | 132 | \PAB{What's a ``side''?} |
---|
[4706098c] | 133 | |
---|
| 134 | \subsection{Termination} |
---|
| 135 | \label{s:Termination} |
---|
| 136 | |
---|
| 137 | Termination raise, called ``throw'', is familiar and used in most programming |
---|
| 138 | languages with exception handling. The semantics of termination is: search the |
---|
| 139 | stack for a matching handler, unwind the stack frames to the matching handler, |
---|
| 140 | execute the handler, and continue execution after the handler. Termination is |
---|
| 141 | used when execution \emph{cannot} return to the throw. To continue execution, |
---|
| 142 | the program must \emph{recover} in the handler from the failed (unwound) |
---|
| 143 | execution at the raise to safely proceed after the handler. |
---|
| 144 | |
---|
| 145 | A termination raise is started with the @throw@ statement: |
---|
| 146 | \begin{cfa} |
---|
[4a36b344] | 147 | throw EXPRESSION; |
---|
[4706098c] | 148 | \end{cfa} |
---|
| 149 | The expression must return a termination-exception reference, where the |
---|
| 150 | termination exception has a type with a @void defaultTerminationHandler(T &)@ |
---|
| 151 | (default handler) defined. The handler is found at the call site using \CFA's |
---|
| 152 | trait system and passed into the exception system along with the exception |
---|
| 153 | itself. |
---|
| 154 | |
---|
| 155 | At runtime, a representation of the exception type and an instance of the |
---|
| 156 | exception type is copied into managed memory (heap) to ensure it remains in |
---|
| 157 | scope during unwinding. It is the user's responsibility to ensure the original |
---|
| 158 | exception object at the throw is freed when it goes out of scope. Being |
---|
| 159 | allocated on the stack is sufficient for this. |
---|
| 160 | |
---|
| 161 | Then the exception system searches the stack starting from the throw and |
---|
| 162 | proceeding towards the base of the stack, from callee to caller. At each stack |
---|
| 163 | frame, a check is made for termination handlers defined by the @catch@ clauses |
---|
| 164 | of a @try@ statement. |
---|
| 165 | \begin{cfa} |
---|
[4a36b344] | 166 | try { |
---|
[4706098c] | 167 | GUARDED_BLOCK |
---|
| 168 | } @catch (EXCEPTION_TYPE$\(_1\)$ * NAME)@ { // termination handler 1 |
---|
| 169 | HANDLER_BLOCK$\(_1\)$ |
---|
| 170 | } @catch (EXCEPTION_TYPE$\(_2\)$ * NAME)@ { // termination handler 2 |
---|
| 171 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 172 | } |
---|
[4706098c] | 173 | \end{cfa} |
---|
| 174 | The statements in the @GUARDED_BLOCK@ are executed. If those statements, or any |
---|
| 175 | functions invoked from those statements, throws an exception, and the exception |
---|
| 176 | is not handled by a try statement further up the stack, the termination |
---|
| 177 | handlers are searched for a matching exception type from top to bottom. |
---|
| 178 | |
---|
| 179 | Exception matching checks the representation of the thrown exception-type is |
---|
| 180 | the same or a descendant type of the exception types in the handler clauses. If |
---|
| 181 | there is a match, a pointer to the exception object created at the throw is |
---|
| 182 | bound to @NAME@ and the statements in the associated @HANDLER_BLOCK@ are |
---|
| 183 | executed. If control reaches the end of the handler, the exception is freed, |
---|
| 184 | and control continues after the try statement. |
---|
| 185 | |
---|
| 186 | The default handler visible at the throw statement is used if no matching |
---|
| 187 | termination handler is found after the entire stack is searched. At that point, |
---|
| 188 | the default handler is called with a reference to the exception object |
---|
| 189 | generated at the throw. If the default handler returns, the system default |
---|
| 190 | action is executed, which often terminates the program. This feature allows |
---|
| 191 | each exception type to define its own action, such as printing an informative |
---|
| 192 | error message, when an exception is not handled in the program. |
---|
| 193 | |
---|
| 194 | \subsection{Resumption} |
---|
| 195 | \label{s:Resumption} |
---|
| 196 | |
---|
| 197 | Resumption raise, called ``resume'', is as old as termination |
---|
| 198 | raise~\cite{Goodenough75} but is less popular. In many ways, resumption is |
---|
| 199 | simpler and easier to understand, as it is simply a dynamic call (as in |
---|
| 200 | Lisp). The semantics of resumption is: search the stack for a matching handler, |
---|
| 201 | execute the handler, and continue execution after the resume. Notice, the stack |
---|
| 202 | cannot be unwound because execution returns to the raise point. Resumption is |
---|
| 203 | used used when execution \emph{can} return to the resume. To continue |
---|
| 204 | execution, the program must \emph{correct} in the handler for the failed |
---|
| 205 | execution at the raise so execution can safely continue after the resume. |
---|
| 206 | |
---|
| 207 | A resumption raise is started with the @throwResume@ statement: |
---|
| 208 | \begin{cfa} |
---|
[4a36b344] | 209 | throwResume EXPRESSION; |
---|
[4706098c] | 210 | \end{cfa} |
---|
| 211 | The semantics of the @throwResume@ statement are like the @throw@, but the |
---|
| 212 | expression has a type with a @void defaultResumptionHandler(T &)@ (default |
---|
| 213 | handler) defined, where the handler is found at the call site by the type |
---|
[1c1c180] | 214 | system. At runtime, a representation of the exception type and an instance of |
---|
[4706098c] | 215 | the exception type is \emph{not} copied because the stack is maintained during |
---|
| 216 | the handler search. |
---|
| 217 | |
---|
| 218 | Then the exception system searches the stack starting from the resume and |
---|
| 219 | proceeding towards the base of the stack, from callee to caller. At each stack |
---|
| 220 | frame, a check is made for resumption handlers defined by the @catchResume@ |
---|
| 221 | clauses of a @try@ statement. |
---|
| 222 | \begin{cfa} |
---|
[4a36b344] | 223 | try { |
---|
[4706098c] | 224 | GUARDED_BLOCK |
---|
| 225 | } @catchResume (EXCEPTION_TYPE$\(_1\)$ * NAME)@ { // resumption handler 1 |
---|
| 226 | HANDLER_BLOCK$\(_1\)$ |
---|
| 227 | } @catchResume (EXCEPTION_TYPE$\(_2\)$ * NAME)@ { // resumption handler 2 |
---|
| 228 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 229 | } |
---|
[4706098c] | 230 | \end{cfa} |
---|
| 231 | The statements in the @GUARDED_BLOCK@ are executed. If those statements, or any |
---|
| 232 | functions invoked from those statements, resumes an exception, and the |
---|
| 233 | exception is not handled by a try statement further up the stack, the |
---|
| 234 | resumption handlers are searched for a matching exception type from top to |
---|
| 235 | bottom. (Note, termination and resumption handlers may be intermixed in a @try@ |
---|
| 236 | statement but the kind of raise (throw/resume) only matches with the |
---|
| 237 | corresponding kind of handler clause.) |
---|
| 238 | |
---|
| 239 | The exception search and matching for resumption is the same as for |
---|
| 240 | termination, including exception inheritance. The difference is when control |
---|
| 241 | reaches the end of the handler: the resumption handler returns after the resume |
---|
| 242 | rather than after the try statement. The resume point assumes the handler has |
---|
| 243 | corrected the problem so execution can safely continue. |
---|
| 244 | |
---|
| 245 | Like termination, if no resumption handler is found, the default handler |
---|
| 246 | visible at the resume statement is called, and the system default action is |
---|
| 247 | executed. |
---|
| 248 | |
---|
| 249 | For resumption, the exception system uses stack marking to partition the |
---|
| 250 | resumption search. If another resumption exception is raised in a resumption |
---|
| 251 | handler, the second exception search does not start at the point of the |
---|
| 252 | original raise. (Remember the stack is not unwound and the current handler is |
---|
| 253 | at the top of the stack.) The search for the second resumption starts at the |
---|
| 254 | current point on the stack because new try statements may have been pushed by |
---|
| 255 | the handler or functions called from the handler. If there is no match back to |
---|
[7eb6eb5] | 256 | the point of the current handler, the search skips\label{p:searchskip} the stack frames already |
---|
[4706098c] | 257 | searched by the first resume and continues after the try statement. The default |
---|
| 258 | handler always continues from default handler associated with the point where |
---|
| 259 | the exception is created. |
---|
[4a36b344] | 260 | |
---|
[02b73ea] | 261 | % This might need a diagram. But it is an important part of the justification |
---|
[4a36b344] | 262 | % of the design of the traversal order. |
---|
[4706098c] | 263 | \begin{verbatim} |
---|
| 264 | throwResume2 ----------. |
---|
| 265 | | | |
---|
| 266 | generated from handler | |
---|
| 267 | | | |
---|
| 268 | handler | |
---|
| 269 | | | |
---|
| 270 | throwResume1 -----. : |
---|
| 271 | | | : |
---|
| 272 | try | : search skip |
---|
| 273 | | | : |
---|
| 274 | catchResume <----' : |
---|
| 275 | | | |
---|
| 276 | \end{verbatim} |
---|
| 277 | |
---|
| 278 | This resumption search-pattern reflect the one for termination, which matches |
---|
| 279 | with programmer expectations. However, it avoids the \emph{recursive |
---|
| 280 | resumption} problem. If parts of the stack are searched multiple times, loops |
---|
| 281 | can easily form resulting in infinite recursion. |
---|
| 282 | |
---|
| 283 | Consider the trivial case: |
---|
| 284 | \begin{cfa} |
---|
| 285 | try { |
---|
| 286 | throwResume$\(_1\)$ (E &){}; |
---|
| 287 | } catch( E * ) { |
---|
| 288 | throwResume; |
---|
| 289 | } |
---|
| 290 | \end{cfa} |
---|
| 291 | Based on termination semantics, programmer expectation is for the re-resume to |
---|
| 292 | continue searching the stack frames after the try statement. However, the |
---|
| 293 | current try statement is still on the stack below the handler issuing the |
---|
[7eb6eb5] | 294 | reresume \see{\VRef{s:Reraise}}. Hence, the try statement catches the re-raise |
---|
[4706098c] | 295 | again and does another re-raise \emph{ad infinitum}, which is confusing and |
---|
| 296 | difficult to debug. The \CFA resumption search-pattern skips the try statement |
---|
| 297 | so the reresume search continues after the try, mathcing programmer |
---|
| 298 | expectation. |
---|
| 299 | |
---|
| 300 | \section{Conditional Catch} |
---|
| 301 | Both termination and resumption handler-clauses may perform conditional matching: |
---|
| 302 | \begin{cfa} |
---|
| 303 | catch (EXCEPTION_TYPE * NAME ; @CONDITION@) |
---|
| 304 | \end{cfa} |
---|
| 305 | First, the same semantics is used to match the exception type. Second, if the |
---|
| 306 | exception matches, @CONDITION@ is executed. The condition expression may |
---|
| 307 | reference all names in scope at the beginning of the try block and @NAME@ |
---|
[1c1c180] | 308 | introduced in the handler clause. If the condition is true, then the handler |
---|
[4706098c] | 309 | matches. Otherwise, the exception search continues at the next appropriate kind |
---|
| 310 | of handler clause in the try block. |
---|
| 311 | \begin{cfa} |
---|
| 312 | try { |
---|
| 313 | f1 = open( ... ); |
---|
| 314 | f2 = open( ... ); |
---|
| 315 | ... |
---|
| 316 | } catch( IOFailure * f ; fd( f ) == f1 ) { |
---|
| 317 | // only handle IO failure for f1 |
---|
| 318 | } |
---|
| 319 | \end{cfa} |
---|
| 320 | Note, catching @IOFailure@, checking for @f1@ in the handler, and reraising the |
---|
| 321 | exception if not @f1@ is different because the reraise does not examine any of |
---|
| 322 | remaining handlers in the current try statement. |
---|
| 323 | |
---|
| 324 | \section{Reraise} |
---|
| 325 | \label{s:Reraise} |
---|
| 326 | Within the handler block or functions called from the handler block, it is |
---|
| 327 | possible to reraise the most recently caught exception with @throw@ or |
---|
| 328 | @throwResume@, respective. |
---|
| 329 | \begin{cfa} |
---|
| 330 | catch( ... ) { |
---|
| 331 | ... throw; // rethrow |
---|
| 332 | } catchResume( ... ) { |
---|
| 333 | ... throwResume; // reresume |
---|
| 334 | } |
---|
| 335 | \end{cfa} |
---|
| 336 | The only difference between a raise and a reraise is that reraise does not |
---|
| 337 | create a new exception; instead it continues using the current exception, \ie |
---|
| 338 | no allocation and copy. However the default handler is still set to the one |
---|
| 339 | visible at the raise point, and hence, for termination could refer to data that |
---|
| 340 | is part of an unwound stack frame. To prevent this problem, a new default |
---|
| 341 | handler is generated that does a program-level abort. |
---|
[4a36b344] | 342 | |
---|
| 343 | |
---|
| 344 | \section{Finally Clauses} |
---|
[4706098c] | 345 | A @finally@ clause may be placed at the end of a @try@ statement. |
---|
| 346 | \begin{cfa} |
---|
[4a36b344] | 347 | try { |
---|
[4706098c] | 348 | GUARDED_BLOCK |
---|
| 349 | } ... // any number or kind of handler clauses |
---|
[4a36b344] | 350 | } finally { |
---|
[4706098c] | 351 | FINALLY_BLOCK |
---|
[4a36b344] | 352 | } |
---|
[4706098c] | 353 | \end{cfa} |
---|
| 354 | The @FINALLY_BLOCK@ is executed when the try statement is unwound from the |
---|
| 355 | stack, \ie when the @GUARDED_BLOCK@ or any handler clause finishes. Hence, the |
---|
| 356 | finally block is always executed. |
---|
| 357 | |
---|
| 358 | Execution of the finally block should always finish, meaning control runs off |
---|
| 359 | the end of the block. This requirement ensures always continues as if the |
---|
| 360 | finally clause is not present, \ie finally is for cleanup not changing control |
---|
[1c1c180] | 361 | flow. Because of this requirement, local control flow out of the finally block |
---|
| 362 | is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or |
---|
[4706098c] | 363 | @return@ that causes control to leave the finally block. Other ways to leave |
---|
| 364 | the finally block, such as a long jump or termination are much harder to check, |
---|
| 365 | and at best requiring additional run-time overhead, and so are discouraged. |
---|
[4a36b344] | 366 | |
---|
| 367 | \section{Cancellation} |
---|
[4706098c] | 368 | Cancellation is a stack-level abort, which can be thought of as as an |
---|
| 369 | uncatchable termination. It unwinds the entirety of the current stack, and if |
---|
| 370 | possible forwards the cancellation exception to a different stack. |
---|
| 371 | |
---|
| 372 | There is no special statement for starting a cancellation; instead the standard |
---|
[1c1c180] | 373 | library function @cancel_stack@ is called passing an exception. Unlike a |
---|
[4706098c] | 374 | raise, this exception is not used in matching only to pass information about |
---|
| 375 | the cause of the cancellation. |
---|
| 376 | |
---|
| 377 | Handling of a cancellation depends on which stack is being cancelled. |
---|
| 378 | \begin{description} |
---|
| 379 | \item[Main Stack:] |
---|
| 380 | The main stack is the one used by the program main at the start of execution, |
---|
[1c1c180] | 381 | and is the only stack in a sequential program. Hence, when cancellation is |
---|
[4706098c] | 382 | forwarded to the main stack, there is no other forwarding stack, so after the |
---|
| 383 | stack is unwound, there is a program-level abort. |
---|
| 384 | |
---|
| 385 | \item[Thread Stack:] |
---|
| 386 | A thread stack is created for a @thread@ object or object that satisfies the |
---|
[1c1c180] | 387 | @is_thread@ trait. A thread only has two points of communication that must |
---|
[4706098c] | 388 | happen: start and join. As the thread must be running to perform a |
---|
| 389 | cancellation, it must occur after start and before join, so join is a |
---|
[1c1c180] | 390 | cancellation point. After the stack is unwound, the thread halts and waits for |
---|
[4706098c] | 391 | another thread to join with it. The joining thread, checks for a cancellation, |
---|
| 392 | and if present, resumes exception @ThreadCancelled@. |
---|
| 393 | |
---|
| 394 | There is a subtle difference between the explicit join (@join@ function) and |
---|
| 395 | implicit join (from a destructor call). The explicit join takes the default |
---|
| 396 | handler (@defaultResumptionHandler@) from its calling context, which is used if |
---|
| 397 | the exception is not caught. The implicit join does a program abort instead. |
---|
| 398 | |
---|
| 399 | This semantics is for safety. One difficult problem for any exception system is |
---|
| 400 | defining semantics when an exception is raised during an exception search: |
---|
| 401 | which exception has priority, the original or new exception? No matter which |
---|
| 402 | exception is selected, it is possible for the selected one to disrupt or |
---|
[7eb6eb5] | 403 | destroy the context required for the other. \PAB{I do not understand the |
---|
| 404 | following sentences.} This loss of information can happen with join but as the |
---|
| 405 | thread destructor is always run when the stack is being unwound and one |
---|
| 406 | termination/cancellation is already active. Also since they are implicit they |
---|
| 407 | are easier to forget about. |
---|
[4706098c] | 408 | |
---|
| 409 | \item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object |
---|
[1c1c180] | 410 | or object that satisfies the @is_coroutine@ trait. A coroutine only knows of |
---|
| 411 | two other coroutines, its starter and its last resumer. The last resumer has |
---|
| 412 | the tightest coupling to the coroutine it activated. Hence, cancellation of |
---|
[4706098c] | 413 | the active coroutine is forwarded to the last resumer after the stack is |
---|
| 414 | unwound, as the last resumer has the most precise knowledge about the current |
---|
| 415 | execution. When the resumer restarts, it resumes exception |
---|
| 416 | @CoroutineCancelled@, which is polymorphic over the coroutine type and has a |
---|
| 417 | pointer to the cancelled coroutine. |
---|
| 418 | |
---|
| 419 | The resume function also has an assertion that the @defaultResumptionHandler@ |
---|
| 420 | for the exception. So it will use the default handler like a regular throw. |
---|
| 421 | \end{description} |
---|