> On Apr 30, 2020, at 3:11 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> If your program’s main thread has an issue because its binding for the current-directory parameter is not /tmp as it should be, then you can simply enter (current-directory "/tmp") in the remote REPL.  It is that simple because the main thread and the REPL thread share the same parameter cells.  With the b semantics you can’t implement this because current-directory is a predefined parameter and you can’t wrap it in a “box” to get the sharing semantics (more generally semantics b doesn’t scale because even if you could easily add the “box” to this parameter, you would also need to change all the places that access the current-directory in all your code and libraries, some of which are part of the runtime system that you can’t change).
>
> I have just noticed that this wouldn't work reliably, would it? The
> setting of parameters needn't be an atomic operation, so one of the
> two threads may see a corrupted state of the current directory. Or do
> you want to make setting parameters an atomic operation, which would
> probably involve locks around every reading and writing of parameters?

The semantics of threads and concurrent writes to a ressource (be it a variable, parameter object, port, etc) is not yet standardized by Scheme (RnRS).  SRFI 18 does specify that “Concurrent reads and writes to ports are allowed. It is the responsibility of the implementation to serialize accesses to a given port using the appropriate synchronization primitives.” but there are no guarantees for other state changing operations.  So an implementation of Scheme with a more constraining semantics (atomic read and writes) can still conform to SRFI 18.  This is the case of Gambit, where read/writes to variables and parameter objects are atomic operations.  You can’t observe a corrupt state when reading and you either get the value just before or just after the write.

Marc