bug#20938: make-dynamic-state, with-dynamic-state & exceptions

[Andy Wingo]

On Wed 01 Mar 2017 16:11, Josep Portella Florit <address@hidden> writes:

> Hi Andy,
>
> On 02/28/2017 03:17 PM, Andy Wingo wrote:
>> On Tue 30 Jun 2015 15:50, Josep Portella Florit <address@hidden> writes:
>> 
>>> This code crashes Guile 2.0.11:
>>>
>>> (define x (make-dynamic-state))
>>> (with-dynamic-state x (lambda () (/ 1 0)))
>> 
>> Sad :/ Fixed in 2.2 though, finally.  I don't really know how to fix it
>> in 2.0 though.  Marking as closed given that we will have a shiny new
>> 2.2.0 soon.
>
> Good work!  Do I have to wait until you release 2.2.0 to test it?
> (Today I've tested it with 2.1.7.22-fcebf and it still crashed.)

Ack, I didn't actually test it!  I thought a related fix in 2.1.7 would
have caught it.  I will have a look.

> BTW, did you change your mind on deprecating dynamic states?
> <http://lists.gnu.org/archive/html/guile-devel/2016-06/msg00104.html>

Yes, with a caveat.  Having captured dynamic states also be mutable
places was untenable, as you could have multiple threads mutating the
same place at one time.  However dynamic states work well as a way to
transport a parameterization from one part of the code to another.  I
rely on them in Fibers for this purpose.  What do you think? :)

See NEWS:

  ** 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*.

And:

  ** Dynamic states capture values, not locations

  Dynamic states used to capture the locations of fluid-value
  associations.  Capturing the current dynamic state then setting a fluid
  would result in a mutation of that captured state.  Now capturing a
  dynamic state simply captures the current values, and calling
  `with-dynamic-state' copies those values into the Guile virtual machine
  instead of aliasing them in a way that could allow them to be mutated in
  place.  This change allows Guile's fluid variables to be thread-safe.
  To capture the locations of a dynamic state, capture a
  `with-dynamic-state' invocation using partial continuations instead.

Andy