[Top][All Lists]

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

Re: Concurrency, again

From: Daniel Colascione
Subject: Re: Concurrency, again
Date: Thu, 27 Oct 2016 12:13:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/27/2016 10:27 AM, Eli Zaretskii wrote:
From: Philipp Stephani <address@hidden>
Date: Tue, 25 Oct 2016 23:28:51 +0000

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


Could you perhaps summarize the relative advantages and disadvantages
of the two concurrency branches?  Your branch doesn't have any
documentation besides doc strings of the new primitives, so it's not
easy to grasp the high-level picture by looking at the details.

One issue that bothers me is whether it's wise to use libtask here,
because the changes you did there seem to imply that we will have to
maintain the library (which is pretty low-level stuff) as part of
Emacs.  Isn't using system threads better?

Agreed on system threads vs libtask. Fibers of the sort libtask provides (similar to GNU Pth) have some claimed advantages in efficiency in large programs with lots of concurrent tasks, but for us, I vote for Python-style use of OS threads with a Python-style GIL that we can release to do long-running computations and recover from parallelism. (I believe the existing concurrency branch runs under this model already, but I'll have to take a closer look.) System threads also have much better integration with the debugger and other development tools; fibers have no offsetting advantages for us.

reply via email to

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