> Hi,
> 
> The known blocker of Elisp support of multi-threading is shared Elisp
> machine state. Handling competing access to global Elisp variables is
> tricky. However, it is not the case for pure side-effect-free functions.
> 
> Consider the following code:
> 
> (let (long-list-of-cons)
>   (dotimes (i 100000)
>     (push (cons i (1+ i)) long-list-of-cons))
>   (mapcar #'car long-list-of-cons))
> 
> The last mapcar looks like a good candidate to run on multiple CPUs.
> I imagine that instead of applying #'car sequentially, Elisp can split
> the list in chunks and run them independently on multiple CPUs. This
> operation is still blocking and thus will not create issues with shared
> access. At the same time such mapcar call will finish much faster.
> 
> Would something like this be feasible to implement in Elisp?
> 
> -- 
> Ihor Radchenko,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> Support Org development at https://liberapay.com/org-mode,
> or support my work at https://liberapay.com/yantar92
>

I think the problem is the interpreter itself, which is not thread-safe.
This looks like a feature request, I think emacs-devel is good for that.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5