source: doc/theses/andrew_beach_MMath/features.tex @ 09ee131

ADTarm-ehast-experimentalenumforall-pointer-decayjacob/cs343-translationnew-ast-unique-exprpthread-emulationqualifiedEnum
Last change on this file since 09ee131 was f28fdee, checked in by Peter A. Buhr <pabuhr@…>, 4 years ago

incorporate uw-thesis macros and CFA common macros

  • Property mode set to 100644
File size: 16.0 KB
Line 
1\chapter{Features}
2
3This chapter covers the design and user interface of the \CFA exception
4handling mechanism.
5
6\section{Virtual Casts}
7
8Virtual casts and virtual types are not truly part of the exception system but
9they did not exist in \CFA and are useful in exceptions. So a minimal version
10of they virtual system was designed and implemented.
11
12Virtual types are organized in simple hierarchies. Each virtual type may have
13a parent and can have any number of children. A type's descendants are its
14children and its children's descendants. A type may not be its own descendant.
15
16Each virtual type has an associated virtual table type. A virtual table is a
17structure that has fields for all the virtual members of a type. A virtual
18type has all the virtual members of its parent and can add more. It may also
19update the values of the virtual members and should in many cases.
20
21Except for virtual casts, this is only used internally in the exception
22system. There is no general purpose interface for the other features. A
23a virtual cast has the following syntax:
24
25\begin{lstlisting}
26(virtual TYPE)EXPRESSION
27\end{lstlisting}
28
29This has the same precedence as a traditional C-cast and can be used in the
30same places. This will convert the result of EXPRESSION to the type TYPE. Both
31the type of EXPRESSION and TYPE must be pointers to virtual types.
32
33The cast is checked and will either return the original value or null, based
34on the result of the check. The check is does the object pointed at have a
35type that is a descendant of the target type. If it is the result is the
36pointer, otherwise the result is null.
37
38\section{Exceptions}
39% Leaving until later, hopefully it can talk about actual syntax instead
40% of my many strange macros. Syntax aside I will also have to talk about the
41% features all exceptions support.
42
43\subsection{Exception Traits}
44Exceptions are defined by the trait system; there are a series of traits and
45if a type satisfies them then they can be used as exceptions.
46
47\begin{lstlisting}
48trait is_exception(dtype exceptT, dtype virtualT) {
49    virtualT const & get_exception_vtable(exceptT *);
50};
51\end{lstlisting}
52This is the base trait that all exceptions need to match.
53The single function takes any pointer (including the null pointer) and
54returns a reference to the virtual table instance. Defining this function
55also establishes the virtual type and virtual table pair to the resolver
56and promises that @exceptT@ is a virtual type and a child of the
57base exception type.
58
59One odd thing about @get_exception_vtable@ is that it should always
60be a constant function, returning the same value regardless of its argument.
61A pointer or reference to the virtual table instance could be used instead,
62however using a function has some ease of implementation advantages and
63allows for easier disambiguation because the virtual type name (or the
64address of an instance that is in scope) can be used instead of the mangled
65virtual table name.
66
67Also note the use of the word ``promise" in the trait description. \CFA
68cannot currently check to see if either @exceptT@ or
69@virtualT@ match the layout requirements. Currently this is
70considered part of @get_exception_vtable@'s correct implementation.
71
72\begin{lstlisting}
73trait is_termination_exception(
74        dtype exceptT, dtype virtualT | is_exception(exceptT, virtualT)) {
75    void defaultTerminationHandler(exceptT &);
76};
77\end{lstlisting}
78The only additional function required to make the exception usable with
79termination is a default handler. This function is called whenever a
80termination throw on an exception of this type is preformed and no handler
81is found.
82
83\begin{lstlisting}
84trait is_resumption_exception(
85        dtype exceptT, dtype virtualT | is_exception(exceptT, virtualT)) {
86    void defaultResumptionHandler(exceptT &);
87};
88\end{lstlisting}
89Creating a resumption exception is exactly the same except for resumption.
90The name change reflects that and the function is called when a resumption
91throw on an exception of this type is preformed and no handler is found.
92
93Finally there are three additional macros that can be used to refer to the
94these traits. They are @IS_EXCEPTION@,
95@IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
96Each takes the virtual type's name and, for polymorphic types only, the
97parenthesized list of polymorphic arguments. These do the name mangling to
98get the virtual table name and provide the arguments to both sides.
99
100\section{Termination}
101
102Termination exception throws are likely the most familiar kind, as they are
103used in several popular programming languages. A termination will throw an
104exception, search the stack for a handler, unwind the stack to where the
105handler is defined, execute the handler and then continue execution after
106the handler. They are used when execution cannot continue here.
107
108Termination has two pieces of syntax it uses. The first is the throw:
109\begin{lstlisting}
110throw EXPRESSION;
111\end{lstlisting}
112
113The expression must evaluate to a reference to a termination exception. A
114termination exception is any exception with a
115@void defaultTerminationHandler(T &);@ (the default handler) defined
116on it. The handler is taken from the call sight with \CFA's trait system and
117passed into the exception system along with the exception itself.
118
119The exception passed into the system is then copied into managed memory.
120This is to ensure it remains in scope during unwinding. It is the user's
121responsibility to make sure the original exception is freed when it goes out
122of scope. Being allocated on the stack is sufficient for this.
123
124Then the exception system will search the stack starting from the throw and
125proceeding towards the base of the stack, from callee to caller. As it goes
126it will check any termination handlers it finds:
127
128\begin{lstlisting}
129try {
130    TRY_BLOCK
131} catch (EXCEPTION_TYPE * NAME) {
132    HANDLER
133}
134\end{lstlisting}
135
136This shows a try statement with a single termination handler. The statements
137in TRY\_BLOCK will be executed when control reaches this statement. While
138those statements are being executed if a termination exception is thrown and
139it is not handled by a try statement further up the stack the EHM will check
140all of the terminations handlers attached to the try block, top to bottom.
141
142At each handler the EHM will check to see if the thrown exception is a
143descendant of EXCEPTION\_TYPE. If it is the pointer to the exception is
144bound to NAME and the statements in HANDLER are executed. If control reaches
145the end of the handler then it exits the block, the exception is freed and
146control continues after the try statement.
147
148The default handler is only used if no handler for the exception is found
149after the entire stack is searched. When that happens the default handler
150is called with a reference to the exception as its only argument. If the
151handler returns control continues from after the throw statement.
152
153\paragraph{Conditional Catches}
154
155Catch clauses may also be written as:
156\begin{lstlisting}
157catch (EXCEPTION_TYPE * NAME ; CONDITION)
158\end{lstlisting}
159This has the same behaviour as a regular catch clause except that if the
160exception matches the given type the condition is also run. If the result is
161true only then is this considered a matching handler. If the result is false
162then the handler does not match and the search continues with the next clause
163in the try block.
164
165The condition considers all names in scope at the beginning of the try block
166to be in scope along with the name introduce in the catch clause itself.
167
168\paragraph{Re-Throwing}
169
170You can also re-throw the most recent termination exception with
171@throw;@. % This is terrible and you should never do it.
172This can be done in a handler or any function that could be called from a
173handler.
174
175This will start another termination throw reusing the exception, meaning it
176does not copy the exception or allocated any more memory for it. However the
177default handler is still at the original through and could refer to data that
178was on the unwound section of the stack. So instead a new default handler that
179does a program level abort is used.
180
181\section{Resumption}
182
183Resumption exceptions are less popular then termination but in many
184regards are simpler and easier to understand. A resumption throws an exception,
185searches for a handler on the stack, executes that handler on top of the stack
186and then continues execution from the throw. These are used when a problem
187needs to be fixed before execution continues.
188
189A resumption is thrown with a throw resume statement:
190\begin{lstlisting}
191throwResume EXPRESSION;
192\end{lstlisting}
193The result of EXPRESSION must be a resumption exception type. A resumption
194exception type is any type that satisfies the assertion
195@void defaultResumptionHandler(T &);@ (the default handler). When the
196statement is executed the expression is evaluated and the result is thrown.
197
198Handlers are declared using clauses in try statements:
199\begin{lstlisting}
200try {
201    TRY_BLOCK
202} catchResume (EXCEPTION_TYPE * NAME) {
203    HANDLER
204}
205\end{lstlisting}
206This is a simple example with the try block and a single resumption handler.
207Multiple resumption handlers can be put in a try statement and they can be
208mixed with termination handlers.
209
210When a resumption begins it will start searching the stack starting from
211the throw statement and working its way to the callers. In each try statement
212handlers will be tried top to bottom. Each handler is checked by seeing if
213the thrown exception is a descendant of EXCEPTION\_TYPE. If not the search
214continues. Otherwise NAME is bound to a pointer to the exception and the
215HANDLER statements are executed. After they are finished executing control
216continues from the throw statement.
217
218If no appropriate handler is found then the default handler is called. The
219throw statement acts as a regular function call passing the exception to
220the default handler and after the handler finishes executing control continues
221from the throw statement.
222
223The exception system also tracks the position of a search on the stack. If
224another resumption exception is thrown while a resumption handler is running
225it will first check handlers pushed to the stack by the handler and any
226functions it called, then it will continue from the try statement that the
227handler is a part of; except for the default handler where it continues from
228the throw the default handler was passed to.
229
230This makes the search pattern for resumption reflect the one for termination,
231which is what most users expect.
232
233% This might need a diagram. But it is an important part of the justification
234% of the design of the traversal order.
235It also avoids the recursive resumption problem. If the entire stack is
236searched loops of resumption can form. Consider a handler that handles an
237exception of type A by resuming an exception of type B and on the same stack,
238later in the search path, is a second handler that handles B by resuming A.
239
240Assuming no other handlers on the stack handle A or B then in either traversal
241system an A resumed from the top of the stack will be handled by the first
242handler. A B resumed from the top or from the first handler it will be handled
243by the second handler. The only difference is when A is thrown from the second
244handler. The entire stack search will call the first handler again, creating a
245loop. Starting from the position in the stack though will break this loop.
246
247\paragraph{Conditional Catches}
248
249Resumption supports conditional catch clauses like termination does. They
250use the same syntax except the keyword is changed:
251\begin{lstlisting}
252catchResume (EXCEPTION_TYPE * NAME ; CONDITION) 
253\end{lstlisting}
254
255It also has the same behaviour, after the exception type has been matched
256with the EXCEPTION\_TYPE the CONDITION is evaluated with NAME in scope. If
257the result is true then the handler is run, otherwise the search continues
258just as if there had been a type mismatch.
259
260\paragraph{Re-Throwing}
261
262You may also re-throw resumptions with a @throwResume;@ statement.
263This can only be done from inside of a @catchResume@ block.
264
265Outside of any side effects of any code already run in the handler this will
266have the same effect as if the exception had not been caught in the first
267place.
268
269\section{Finally Clauses}
270
271A @finally@ clause may be placed at the end of a try statement after
272all the handler clauses. In the simply case, with no handlers, it looks like
273this:
274
275\begin{lstlisting}
276try {
277    TRY_BLOCK
278} finally {
279    FINAL_STATEMENTS
280}
281\end{lstlisting}
282
283Any number of termination handlers and resumption handlers may proceed the
284finally clause.
285
286The FINAL\_STATEMENTS, the finally block, are executed whenever the try
287statement is removed from the stack. This includes: the TRY\_BLOCK finishes
288executing, a termination exception finishes executing and the stack unwinds.
289
290Execution of the finally block should finish by letting control run off
291the end of the block. This is because after the finally block is complete
292control will continue to where ever it would if the finally clause was not
293present.
294
295Because of this local control flow out of the finally block is forbidden.
296The compiler rejects uses of @break@, @continue@,
297@fallthru@ and @return@ that would cause control to leave
298the finally block. Other ways to leave the finally block - such as a long
299jump or termination - are much harder to check, at best requiring additional
300run-time overhead, and so are merely discouraged.
301
302\section{Cancellation}
303
304Cancellation can be thought of as a stack-level abort or as an uncatchable
305termination. It unwinds the entirety of the current exception and if possible
306passes an exception to a different stack as a message.
307
308There is no special statement for starting a cancellation, instead you call
309the standard library function @cancel\_stack@ which takes an exception.
310Unlike in a throw this exception is not used in control flow but is just there
311to pass information about why the cancellation happened.
312
313The handler is decided entirely by which stack is being canceled. There are
314three handlers that apply to three different groups of stacks:
315\begin{itemize}
316\item Main Stack:
317The main stack is the one on which the program main is called at the beginning
318of your program. It is also the only stack you have without the libcfathreads.
319
320Because of this there is no other stack ``above" (or possibly at all) for main
321to notify when a cancellation occurs. So after the stack is unwound we do a
322program level abort.
323
324\item Thread Stack:
325Thread stacks are those created @thread@ or otherwise satisfy the
326@is\_thread@ trait.
327
328Threads only have two structural points of communication that must happen,
329start and join. As the thread must be running to preform a cancellation it
330will be after start and before join, so join is one cancellation uses.
331
332After the stack is unwound the thread will halt as if had completed normally
333and wait for another thread to join with it. The other thread, when it joins,
334checks for a cancellation. If so it will throw the resumption exception
335@ThreadCancelled@.
336
337There is a difference here in how explicate joins (with the @join@
338function) and implicate joins (from a destructor call). Explicate joins will
339take the default handler (@defaultResumptionHandler@) from the context
340and use like a regular through does if the exception is not caught. The
341implicate join does a program abort instead.
342
343This is for safety. One of the big problems in exceptions is you cannot handle
344two terminations or cancellations on the same stack as either can destroy the
345context required for the other. This can happen with join but as the
346destructors will always be run when the stack is being unwound and one
347termination/cancellation is already active. Also since they are implicit they
348are easier to forget about.
349
350\item Coroutine Stack:
351Coroutine stacks are those created with @coroutine@ or otherwise
352satisfy the @is\_coroutine@ trait.
353
354A coroutine knows of two other coroutines, its starter and its last resumer.
355The last resumer is ``closer" so that is the one notified.
356
357After the stack is unwound control goes to the last resumer.
358Resume will resume throw a @CoroutineCancelled@ exception, which is
359polymorphic over the coroutine type and has a pointer to the coroutine being
360canceled and the canceling exception. The resume function also has an
361assertion that the @defaultResumptionHandler@ for the exception. So it
362will use the default handler like a regular throw.
363
364\end{itemize}
Note: See TracBrowser for help on using the repository browser.