On Tue, Mar 07, 2017 at 10:23:02AM +0100, Andy Wingo wrote: > On Mon 06 Mar 2017 22:44, Vladimir Zhbanov <vzhba...@gmail.com> writes: > > > What I tried so far is to manually save dynamic state in repl: > > (define ds (current-dynamic-state)) > > > > and use it in GUI (with support of guile expression evaluation): > > (with-dynamic-state ds (lambda () (write-history history-filename))) > > > > This is for readline history saving, and works pretty well. > > > > So I was thinking to bake something like this into the above code, > > probably by adding a variable on the repl-eval stage to store > > initial dynamic state in repl. The problem occured when I started > > to call (quit) or (throw 'quit) the same way, that is, in the > > thunk called in with-dynamic-state. It just segfaulted. > > > > And my app is tied to 2.0 these days. > > There is a bug in 2.0 (and actually in 2.2 as well; closer to being > fixed but not fixed entirely) about moving dynamic states between > threads. Basically the dynamic state also captures exception handlers, > but attempting to handle the exceptions tries to abort to prompts that > aren't live, leading to sadness. This NEWS entry discusses part of the > problem: > > ** Fix too-broad capture of dynamic stack by delimited continuations > > Guile was using explicit stacks to represent, for example, the chain of > current exception handlers. This means that a delimited continuation > that captured a "catch" expression would capture the whole stack of > exception handlers, not just the exception handler added by the "catch". > This led to strangeness when resuming the continuation in some other > context like other threads; "throw" could see an invalid stack of > exception handlers. This has been fixed by the addition of the new > "fluid-ref*" procedure that can access older values of fluids; in this > way the exception handler stack is now implicit. See "Fluids and > Dynamic States" in the manual, for more on fluid-ref*. > > I don't know if we will be able to fix this in 2.0 or not :/ I'm very > sorry that you have run into all these problems though!
Thank you for the explanation! -- Vladimir
