[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Asynchronous Requests from Emacs Dynamic Modules"
From: |
Eli Zaretskii |
Subject: |
Re: "Asynchronous Requests from Emacs Dynamic Modules" |
Date: |
Mon, 02 Nov 2020 17:22:12 +0200 |
> From: Akira Kyle <ak@akirakyle.com>
> Cc: yyoncho@gmail.com, all_but_last@163.com, emacs-devel@gnu.org,
> monnier@iro.umontreal.ca, p.stephani2@gmail.com
> Date: Sun, 01 Nov 2020 13:15:43 -0700
>
> Sorry I meant not that it directly exposes pthreads but that its
> interface is modeled off of pthreads (i.e. mutexes, condition
> variables), but lisp should really have some higher level
> interface to parallel and concurrent execution (like Python's
> multiprocessing or asyncio interface). Perhaps it can be built on
> top of the current lisp threading interface, but it seems there
> may be some limitations that make that difficult.
Maybe it can, but I'm not sure I see the need yet. What exactly is
wrong with the existing primitives? After all, the Lisp threads _are_
threads, so basic thread operations for them do make sense.
> > The main use case is to allow you to write one or more background
> > Lisp programs that go about their job while a foreground command
> > lets the user interact normally with Emacs.
>
> Right, but due to the global lock this only allows for concurrent
> execution, and due to the cooperative nature needing one to
> explicitly yield execution for threads to switch, it seems like in
> reality it would be very cumbersome to work with.
Emacs yields automatically when it waits for input, so the idea was
that it wouldn't be cumbersome.
> Do you know of anyone who uses it? I'd be very interested in seeing
> some examples how to successfully use it.
Michael Albinus did, I think you can see his work on a branch in our
Git repository.
> I think libraries like emacs-aio [1] accomplish the same thing but
> with a much easier to use interface. By using (run-at-time 0 nil
> callback args) they accomplish a sort of "green threading" that
> doesn't actually need any sort of pthread support or the
> associated issues with ensuring atomicity with the interpreter. It
> would be great to have something like this built in.
run-at-time is our poor man's threading from years ago; Lisp threads
were supposed to make such background applications easier to
implement.