Re: Concurrency, again

[SAKURAI Masashi]

At Wed, 12 Oct 2016 11:19:11 -0700,
John Wiegley wrote:
> :
> What we're talking about here is not the kind of concurrency that leads to
> nightmares involving corruption of global state, but cooperative concurrency.
> Think of it as "timers, done right", if that helps. It would make a library
> like emacs-deferred trivial to write, for example, which today is tortuously
> implemented on top of the hackish timers we have now.

emacs-deferred is built on tick-timer function (as browser's Promise
implementations do), and provides async APIs not only to run async
tasks but also to connect them without callback continuation.

I have made many programs on it and built async RPC to use desired
functions of other language environments from emacs. In my experience
so far, emacs-deferred has worked well. (I know some issues on github,
but now I have no time to revise it, such as lexbind and cl-lib.)

Then, I have learned that race bug, dead-lock and not-reproducible bug
are terrible even in the single-thread model, and I realized we should
choose concurrent programming without shared mutable state or locking.

So, I think multi-process model with IPC messaging is better for
emacs, like browser's web-worker. I think they have helpful knowledge
about retrofitted concurrency: why did they design the isolated thread
with messaging, not simple thread API?

--
SAKURAI, Masashi (family, given)
address@hidden