Re: Shrinking the C core

[Emanuel Berg <incal@dataswamp.org>]

Rudolf Schlatte wrote:

> So race conditions resulting from multiple threads modifying
> Lisp data structures concurrently are entirely the
> programmer's responsibility in SBCL, to be handled by using
> the provided standard tools (mutexes, locks, condition
> variables etc). So if you create an application in CL, you
> have to check that the libraries you use are thread-safe.
> For Emacs, where multiple applications and libraries are
> assembled into an editor by the end user, instead of
> a programmer creating one application to be run in isolation
> in an SBCL image, I believe this approach will not work.

Since Lisp is and should be the EVERYTHING language, it is all
well and good that the programmer can do that, however - we
should aim at the other end of everythingness as well -
namely, to have Elisp do that seamlessly and on the fly so
that multicored Elisp in execution would happen whenever
beneficial also (especially) when executing normal, including
all existing for that matter, Elisp code.

However, as a first step toward that, we would indeed welcome
specific constructs, e.g.

(let-para ((one (...))
           (two (...)) )
  (compute one two) )

Where 'para' is for "parallel" and would work as this, 'one'
would be computed on CPU core 1, 'two' on CPU core 2 -
starting simultaneously and executing in parallel as you might
have guessed - and the body, in this case "compute", would be
evaluated when both are done.

How would you do that?

At least we don't have to bother with let-para* LOL

-- 
underground experts united
https://dataswamp.org/~incal