A Scheme interpreter can be written in a way so that terminating the thread does not leave the REPL and the rest of the system in an inconsistent state. This is at least the case with existing Scheme implementations, I think.
What if one end of a go-channel is open in the thread and the other end in the REPL? This is a perfectly reasonable REPL feature to have when debugging goroutines.
You just have to make channels thread-termination-safe, which is actually a good thing so that a user just using this protocol does not have to worry about an inconsistent state if one thread/worker/future is forcibly terminated. I think this goes along with your remark below about reading a clock from a channel.
In SRFI 18, Marc gives an example of a mailbox that behaves gracefully when threads are forcibly terminated (his second mailbox example).
That makes me think that `eval` ought to set an initial continuation frame.
This would be incompatible with the semantics of `eval` as defined by the Scheme reports. A REPL implementation should/must wrap `eval` explicitly in `call-in-initial-continuation`. BTW, this is one more example of the usefulness of `call-in-initial-continuation`.
If the time structure is still crucial even after the forced termination of any thread, the protocol could be as follows: The time structure comes with a shadow field and an atomic flag. The mutex is locked when it is updated by a thread. Then the shadow field is populated with the updated current time. Afterward, the atomic flag is raised. Then the time is copied from the shadow field. Finally, the atomic flag is lowered and the mutex is unlocked.
(The complexity of this protocol is a fine reason why programs that need a clock like this should read the value from a channel.)
Yes; this complex protocol is only necessary if your program may forcefully terminate a thread that updates the clock and if it is still needed afterward.
This is why I wrote earlier that the scenario in which arbitrary threads will be forcibly terminated is not a relevant one.