On Mon, Mar 2, 2009 at 9:48 PM, Peter Bex <peter....@xs4all.nl> wrote: > > However, it turns out that an exception thrown in a thread simply > terminates the thread instead of unwinding the stack. The same does not > happen in the primordial thread: >
Ok, here is what Marc Feeley, the author of SRFI-18 has to say about this: >> I have a question about SRFI-18: the default exception handler >> for a thread (the one that stores the thrown object in the >> thread to be later accessed via thread-join!), should it invoke >> dynamic-wind after thunks? > >No the default exception handler shouldn't invoke the after thunks of the >current continuation. That's because the >exception handler doesn't >"continue" at the initial continuation of that thread. Here are the relevant >words of SRFI >18: > > Moreover, in this dynamic environment the exception handler > is bound to the "initial exception handler" which is a unary > procedure which causes the (then) current thread to store in > its end-exception field an "uncaught exception" object whose > "reason" is the argument of the handler, abandon all mutexes > it owns, and finally terminate. > >The rationale is that, when an uncaught exception occurs in a thread the >thread is in bad shape and things have >gone sufficiently wrong that there is >no universally acceptable way to continue execution. Executing after thunks >>could require a whole lot of processing that the thread is not in a shape to >do. So the safe thing is to terminate >the thread. If the programmer knows >how to recover from an exception, then he can capture the continuation >early >on, and install an exception handler which invokes the continuation. When the >continuation is invoked the >after thunks will execute. > >Hope that clarifies things. Hope that clarifies things. cheers, felix _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users