[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: threads & dynamic environment & continuations

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.



> I don't believe the spec states the (obvious) fact that preemptively switching
> between two threads, or yielding or otherwise blocking does *not* cause
> DYNAMIC-WIND's to fire. (By the way, I think DYNAMIC-WIND is a very bad idea,
> in general. I opposed its introduction because of its bad interaction with the
> notion of thread concurrency, and here we are, tripping over it.)

I also oppose dynamic-wind for those reasons and if I could only
change one thing about R5RS it would be to remove dynamic-wind (the
second thing would be to remove multiple values, but that is more
controversial, are you listening Siskind?).

> I think the current document should state these things explicitly. To sum up:
>     - dynamic env is part of the continuation, 
>     - hence, throwing to a continuation changes the dynamic env.

This was so "obvious" to me that I did not mention it.  On the other
hand, is it the role of SRFI 18 to specify this, or a dynamic
environment SRFI?

As for call/null-continuation, you can get the same result with
call-with-current-continuation, if you also have dynamic variables.
I.e. you capture the primordial continuation of the thread and bind
that to a dynamic variable that you can then use to return to the
primordial continuation.

Should SRFI 18 specify a mechanism for manipulating the dynamic
environment?  I'm fond of:

   (dynamic-define var-name expression)
   (dynamic-let ((var-name expression)) body)
   (dynamic-ref var-name)
   (dynamic-set! var-name expression)

Note that in this scheme, dynamic variables and lexically scoped
variables are completely independent.

Marc