Concurrency Library

Concurrency Library

[Zach Shaftel]

I'm wondering if there's interest in a library which wraps threads,
mutices and condition-variables into higher level constructs like
futures, readers-writer locks, agents, concurrent queues etc. I'm
considering this as a project for Summer of Code, but not sure if
it's something others would want included with Emacs.

I can say from personal experience that I don't bother making
programs concurrent in languages with only primitives like mutices
and semaphores, but in Clojure I'll happily spin up agents to
coordinate work. My hope is that the concision and built-in safety
provided by these abstractions could encourage more authors to make
their ELisp programs concurrent.

Thoughts?

-Zach

Re: Concurrency Library

[Eli Zaretskii]

> From: Zach Shaftel <zshaftel@gmail.com>
> Date: Mon, 30 Mar 2020 23:42:08 -0400
> 
> I'm wondering if there's interest in a library which wraps threads,
> mutices and condition-variables into higher level constructs like
> futures, readers-writer locks, agents, concurrent queues etc. I'm
> considering this as a project for Summer of Code, but not sure if
> it's something others would want included with Emacs.

I think it could be useful, yes.

Thanks.

Re: Concurrency Library

[Ag Ibragimov]

I would love to see Clojure's core.async ported to elisp.

On Mon 30 Mar 2020 at 20:42, Zach Shaftel <zshaftel@gmail.com> wrote:

> I'm wondering if there's interest in a library which wraps threads,
> mutices and condition-variables into higher level constructs like
> futures, readers-writer locks, agents, concurrent queues etc. I'm
> considering this as a project for Summer of Code, but not sure if
> it's something others would want included with Emacs.
>
> I can say from personal experience that I don't bother making
> programs concurrent in languages with only primitives like mutices
> and semaphores, but in Clojure I'll happily spin up agents to
> coordinate work. My hope is that the concision and built-in safety
> provided by these abstractions could encourage more authors to make
> their ELisp programs concurrent.
>
> Thoughts?
>
> -Zach

Re: Concurrency Library

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


  > > I'm wondering if there's interest in a library which wraps threads,
  > > mutices and condition-variables into higher level constructs like
  > > futures, readers-writer locks, agents, concurrent queues etc. I'm
  > > considering this as a project for Summer of Code, but not sure if
  > > it's something others would want included with Emacs.

Adding these facilities to Emacs Lisp could be very nice.

  > I would love to see Clojure's core.async ported to elisp.

If "ported to Elisp" means adding its features to Emacs Lisp in a
clean way, I'm in favor.  But we should think about the interfaces and
consider whether some changes in them would fit Lisp better.  Clojure
is like Lisp in many ways, but it does not have Lisp lists.

If it means inserting the code used in Clojure into Emacs Lisp,
I think that isn't the way to do it right.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Concurrency Library

[Zhu Zihao]

There was promise(abstraction of a future value)

https://github.com/chuntaro/emacs-promise

And I am working on a ReactiveX like project to provide observable for Emacs
Lisp.

https://github.com/cireu/emacs-rstream

Re: Concurrency Library

[Zach Shaftel]

> Adding these facilities to Emacs Lisp could be very nice.

Very glad to hear it, I've submitted the proposal so hopefully I'll be able to
work on this project soon.

> > I would love to see Clojure's core.async ported to elisp.

I'll certainly look into it, though it probably is outside the scope of a summer
project. I do of course intend to continue the project after GSoC, so that could
be a future endeavor. Perusing the source and docs, core.async relies on thread
pools and I think readers-writer locks, which are among the first few constructs
I plan to implement.

> If "ported to Elisp" means adding its features to Emacs Lisp in a
> clean way, I'm in favor.  But we should think about the interfaces and
> consider whether some changes in them would fit Lisp better.  Clojure
> is like Lisp in many ways, but it does not have Lisp lists.
>
> If it means inserting the code used in Clojure into Emacs Lisp,
> I think that isn't the way to do it right.

I agree, the library should certainly be tailored to Emacs's strengths and
conform to Elisp's idioms, and figuring out the best way to do that is the first
step in my proposal.

-Zach