Am Do., 8. Sept. 2022 um 01:38 Uhr schrieb John Cowan <[email protected]>:
> > > On Wed, Sep 7, 2022 at 4:55 PM Marc Nieper-Wißkirchen < > [email protected]> wrote: > > 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. [...] Marc
