From: Akira Kyle <ak@akirakyle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: p.stephani2@gmail.com, emacs-devel@gnu.org, yyoncho@gmail.com,
monnier@iro.umontreal.ca, all_but_last@163.com
Subject: Re: "Asynchronous Requests from Emacs Dynamic Modules"
Date: Sun, 01 Nov 2020 13:15:43 -0700 [thread overview]
Message-ID: <86a6w0omts.fsf@akirakyle.com> (raw)
In-Reply-To: <837dr5exsq.fsf@gnu.org>
On Sun, Nov 01, 2020 at 11:28 AM, Eli Zaretskii <eliz@gnu.org>
wrote:
>> It seems the lisp threading functionality is still pretty beta
>> quality. Have the data races that Chris Wellons mentions here
>> [1]
>> ever been addressed?
>
> It's hard to tell, because that blog has no specifics, just a
> broad
> accusation. It is also quite old.
>
>> It looks like it's mostly just exposing the pthread interface.
>
> That's simply not true. It _uses_ pthreads to start and manage
> threads, and to implement mutexes, condvars, etc. But if you
> look
> closely at the level of thread.c (_not_ systhread.c), you will
> see
> something very different from a typical pthreads application.
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.
>> What is the use case for the current lisp threads given the
>> severe
>> limitation that only will ever run at a time and the
>> constraints the
>> cooperative nature puts on when threads can switch?
>
> 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. Do you know of
anyone who uses it? I'd be very interested in seeing some examples
how to successfully use it.
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.
[1] https://github.com/skeeto/emacs-aio
next prev parent reply other threads:[~2020-11-01 20:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 21:35 "Asynchronous Requests from Emacs Dynamic Modules" Akira Kyle
2020-10-30 22:39 ` Stefan Monnier
2020-10-31 3:18 ` Zhu Zihao
2020-10-31 7:45 ` Eli Zaretskii
2020-10-31 8:02 ` yyoncho
2020-10-31 9:13 ` Eli Zaretskii
2020-10-31 9:45 ` yyoncho
2020-10-31 10:43 ` Eli Zaretskii
2020-10-31 19:25 ` Akira Kyle
2020-10-31 20:18 ` Eli Zaretskii
2020-11-01 0:14 ` Akira Kyle
2020-11-01 18:28 ` Eli Zaretskii
2020-11-01 20:15 ` Akira Kyle [this message]
2020-11-01 20:51 ` async-await (was: Re: "Asynchronous Requests from Emacs Dynamic Modules") Philipp Stephani
2020-11-02 15:22 ` "Asynchronous Requests from Emacs Dynamic Modules" Eli Zaretskii
2020-10-31 7:36 ` Philipp Stephani
2020-10-31 12:49 ` Stefan Monnier
2020-11-01 20:18 ` Akira Kyle
2020-11-01 20:32 ` Philipp Stephani
2020-11-20 15:54 ` Zhu Zihao
2020-11-20 16:04 ` Robert Pluim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86a6w0omts.fsf@akirakyle.com \
--to=ak@akirakyle.com \
--cc=all_but_last@163.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=p.stephani2@gmail.com \
--cc=yyoncho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).