Re: Concurrency, again

[Christopher Allan Webber]

Daniel Colascione writes:

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

Python's GIL + threading is probably not the best model to work off
of... while the GIL is largely misunderstood, there have been a lot of
challenges with getting this model to work nice.  At one point, it
turned out that the GIL + threads would result in constant CPU
thrashing.  This isn't the case any more, but it was once, and was a
challenging thing to fix:

  http://dabeaz.com/python/UnderstandingGIL.pdf

Even now, my understanding is that Python does a ton of context
switching, and while it's better than it was, you don't really get a lot
of the performance you would over threads being used in other systems,
because it's hard for Python to really run things concurrently.  Thus
the rise of things like asyncio, where instead of parallelizing, you
break things into a lot of coroutines which don't block on any IO.

Other mechanisms like green threading + coroutines for most IO bound
async stuff and, in the case that you need CPU bound stuff to be
optimized, something that spawns independent processes (or okay, maybe
threads) that communicate with message passing is probably much better
than a GIL + system threads route, I'd think?