Re: Concurrency, again

[Stefan Monnier]

>> > One possibility: move to a multiple processes paradigm where each
>> > buffer has an associated process, and global variable values are
>> > propagated via message passing to a master process.

Yes, I also like this paradigm, and it might work for a significant part
of existing Elisp code.  But that means (with-current-buffer <buf> <code>)
is turned into something like

    (send <buf> (lambda ()
                  (let ((result <code>))
                    (send <current-buffer> (lambda () <continuation>)))))

which in turns pretty much implies that

    (eq (w-c-b buf (point)) (w-c-b buf (point)))

might not always be t since some other code might be executed between
the two w-c-b.  So it breaks some assumptions which current code might
(and sometimes does) rely on.

To avoid this, we'd have to make it so that with-current-buffer takes
a lock on the buffer, but that gets us into the world of deadlocks.

> OTOH, I've become fairly convinced over time that what is preferable
> are paradigms where there is zero shared low level state between
> executing processes.

Amen.

BTW, in the case of Emacs, something like STM would be great: its
potential lackluster performance wouldn't be too much of an issue.
The problem is that it fundamentally needs to adorn *all* code that
changes shared state (and all code which might have irreversible
side-effects), which would require an enormous amount of work.


        Stefan