[Top][All Lists]

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

Re: Concurrency, again

From: Tom Tromey
Subject: Re: Concurrency, again
Date: Mon, 31 Oct 2016 00:42:58 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

>>>>> "Philipp" == Philipp Stephani <address@hidden> writes:

Philipp> I've pushed the experimental branch to
Philipp> 'concurrency-libtask'. It's essentially a simple wrapper around
Philipp> libtask, which implements CSP based on setcontext. I've also
Philipp> implemented a Windows equivalent based on Windows native
Philipp> fibers, but haven't tried that yet.

I took a quick look at it.

I think one thing to know is that the existing concurrency branch has
two distinct parts.  One part is changing various bits of Emacs
internals to cope with multiple threads.  The other part is the design
and implementation of the thread API that is exposed to Emacs Lisp.

IMO the concurrency branch's approach to the internals changes is
generally preferable here.  There are a few issues I saw:

* AFAICT concurrency-libtask doesn't correctly handle updating let
  bindings when task switching;
* It doesn't make the match data per-task;
* Nor the current buffer;
* It doesn't handle the case where multiple tasks select on an fd
  at the same time (the concurrency branch also adds process locking,
  which I thought was handy)

These could be solved of course -- they're already all solved on the
concurrency branch.  There may be more things there that I've forgotten
about as well.

If channels are preferred to locks, it doesn't seem hard to either
simply make channels the API on the concurrency branch; or just write
channels as some lisp around the current code.


reply via email to

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