From: Jim Porter <jporterbugs@gmail.com>
To: emacs-devel@gnu.org
Subject: [RFC] Adding threads to Eshell
Date: Thu, 15 Dec 2022 18:37:09 -0800 [thread overview]
Message-ID: <7f4e3357-2c6a-a0d2-cab5-fb641b52877a@gmail.com> (raw)
First, a bit of context. For those who don't know, Eshell has an
"iterative evaluation" feature, where any time you run an asynchronous
command (like an external process), it yields execution back to the rest
of Emacs so you're not stuck waiting for a long-running command. This is
handled by having Eshell evaluate Lisp forms step-by-step (see
'eshell-do-eval' in lisp/eshell/esh-cmd.el). This requires a lot of code
to handle various Lisp special forms, and the allowed forms are fairly
limited. It also has a few bugs, likely due in part to being written
before lexical binding.
Because of this (especially the bugs), I think it would be good to
retire 'eshell-do-eval' and switch to something else. Initially, I filed
bug#57635 to switch over to generator.el's machinery, but then I
realized that Emacs threads might work even better. In addition to
fixing the bugs (which would unlock several new features), I think
threads would make it pretty straightforward to add job control to
Eshell. I did a few quick tests, and found that it only took a bit of
work to get the basics working with threads.
However, before I go too far, I wanted to check with other, more
knowledgeable people: are Emacs threads available on all platforms? It
looks like it requires the pthreads library (though my understanding was
that Emacs threads aren't "real" threads, since there's no good way to
avoid data races with globals). If we want to support asynchronous
execution in Eshell on systems that don't have access to Emacs threads,
that might be a problem. On the other hand, if those systems *also* lack
support for asynchronous processes, then we're probably ok: on those
systems, Eshell already does most execution synchronously anyway.
A second issue I noticed is that Emacs threads have their own,
completely separate set of lexical bindings. Is it possible to tell a
thread that I want to inherit the bindings from wherever I called
'make-thread'? I might be able to avoid this issue, but it would be nice
to be able to let-bind some defvars and then pass those bindings to an
Eshell command to do its thing.
Depending on how people respond, I could go with either Emacs threads or
some abstraction of generator.el's machinery to upgrade Eshell's
iterative evaluation. Whichever way I go, I'm planning on making a
feature branch once I have something ready for others to look at, since
it's shaping up to be a pretty big change.
next reply other threads:[~2022-12-16 2:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 2:37 Jim Porter [this message]
2022-12-16 14:05 ` [RFC] Adding threads to Eshell Stefan Monnier
2022-12-16 20:11 ` Jim Porter
2022-12-17 3:40 ` Stefan Monnier
2022-12-17 5:19 ` Jim Porter
2022-12-16 19:51 ` Eli Zaretskii
2022-12-16 20:25 ` Jim Porter
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7f4e3357-2c6a-a0d2-cab5-fb641b52877a@gmail.com \
--to=jporterbugs@gmail.com \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.