The mechanism ¶

So, how does it work? The idea is to define the concept of dynamic extent termination of a call to function; this concept is defined by Vicare’s unwind–protection mechanism and it is not a r6rs concept. To understand the unwind–protection mechanism we must understand the concepts “dynamic extent of a function call” and “dynamic environment”.

The procedure ?clean-up is called when the dynamic extent of the invocation of ?thunk terminates; dynamic extent termination is different from dynamic extent exiting as determined by dynamic-wind. When the execution flow exits the dynamic extent of a function call: such extent might also terminate, but not all the exits are also terminations.

In this discussion, we consider the syntax use:

(with-unwind-protection ?clean-up ?thunk)

the dynamic extent of a call to ?thunk is terminated, and so ?clean-up is invoked, when:

• ?thunk performs a normal return. ?clean-up is applied to the symbol ‘return’.
• ?thunk raises a continuable or non–continuable exception that is intercepted by a use of guard, but only when a clause of guard has a test expression returning non–false. If we do:

  (guard (E (?test ?expr))
    (with-unwind-protection
        ?clean-up
      (lambda ()
        (error #f "I know what you did"))))
  

  this is what happens:

  1. The clause’s ?test expression is evaluated in the dynamic environment of the use of guard and it returns non–false.
  2. The ?clean-up is called in the dynamic environment of the use of with-unwind-protection and its return values discarded. ?clean-up is applied to the symbol ‘exception’.
  3. The clause’s ?expr is evaluated in the dynamic environment of the use of guard and its return values are returned to the continuation of guard.
• ?thunk executes a use of the fluid syntaxes break, continue or return, as defined by the library (vicare), to escape from a form that encloses an unwind–protection syntax. ?clean-up is applied to the symbol ‘escape’.

  As bound by the loop syntaxes while, until, … and the syntax returnable: these fluid syntaxes reinstate a continuation at the beginning or outside of while, until, … and returnable and perform special operations to terminate the dynamic extent of the call to ?thunk in an unwind–protection form.

The dynamic extent of a call to ?thunk is not terminated, and so ?clean-up is not invoked, when:

• ?thunk raises a continuable exception by calling raise-continuable, and such call performs a normal return to ?thunk.
• ?thunk raises a continuable or non–continuable exception and an exception handler terminates the process (for example by calling exit).
• The unwind–protection syntax is used by a coroutine and yield is called from within ?thunk to hand control to another coroutine.
• An escape procedure is called from within ?thunk to reinstate a continuation outside ?thunk, and the call to the escape procedure is not interfaced with the unwind–protection mechanism to terminate the dynamic extent of the call to ?thunk.

About the termination of the dynamic extent of ?thunk, we must acknowledge that:

• There is no guarantee that: after exiting (without terminating) the dynamic extent of ?thunk by reinstating a continuation, such extent will be reentered later and continue to termination.
• If the dynamic extent of ?thunk is terminated and an attempt to reenter ?thunk is performed: an exception is raised with compound condition object containing a &non-reinstatable component.
• If the call to ?thunk raises an exception and the consequent call to ?clean-up raises a second exception: the clean–up operation may fail (and, for example, leave the resource unreleased and in an incorrect state).
• If the call to ?thunk raises an exception and a use of guard intercepts it: if a test expression in a clause of guard raises a second exception, the ?clean-up may not be called.
• If the call to ?thunk raises an exception and the in–guard or out–guard thunks of dynamic-wind raise a second exception: the clean–up operation may fail (and, for example, leave the resource unreleased and in an incorrect state).

Things to notice:

• While it is possible to raise any object: it is better to always raise a condition object (possibly compound), so that the test expressions in guard uses can just be condition object type predicates; such predicates never raise exceptions.
• If a second exception is raised while handling the first exception: the unwind–protection mechanism misbehaves.

The problem of the second exception does not haunt only Vicare; if I understand correctly, unwind-protect as defined by Common Lisp also presents cases where the clean–up forms may not be called.

How do we manage resources then? ¶

The unwind–protection mechanism has the purpose of evaluating code when the dynamic extent of a function call terminates; it can be used to release synchronous resources: resources whose life must terminate when the dynamic extent of a function call terminates. Whenever possible, we must take care of handling exceptions with guard before they cross the unwind–protection boundary. So, with compensations, we might do:

(with-compensations
  (guard (E (?test ?expr)
            ...)
    (define ?resource-reference
      (compensate
          ?alloc
        (with
          ?release)))
    ...
    ?body0
    ?body
    ...))

or, if we like try:

(with-compensations
  (try
      (letrec
          ((?resource-reference (compensate
                                    ?alloc
                                  (with
                                    ?release)))
            ...)
        ?body0
        ?body
        ...)
    (catch E
      ((?condition-type)
        ?expr)
      ...)))