[Top][All Lists]

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

Re: Concurrency, again

From: John Wiegley
Subject: Re: Concurrency, again
Date: Wed, 12 Oct 2016 16:33:16 -0700
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (darwin)

>>>>> "SM" == Stefan Monnier <address@hidden> writes:

>>> > 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.

SM> Yes, I also like this paradigm, and it might work for a significant part
SM> of existing Elisp code.

You can try out the paradigm today with async.el, since that's exactly what it

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

If we distinguish between pure and impure forms in the evaluator, we could
enforce that STM transactions are only allowed using pure forms, plus
interactions with transactional variables. This is all that Haskell lets you
to do, but it's quite enough for effective inter-thread communication.

However, if the concurrency we allow is cooperative, all we need to do is
disallow yielding within blocks marked as atomic.

John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

reply via email to

[Prev in Thread] Current Thread [Next in Thread]