From: Paul Michael Reilly <pmr@pajato.com>
To: Stephen Eilert <spedrosa@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Very interesting analysis of "the state of Emacs"
Date: Wed, 30 Apr 2008 02:24:55 -0400 [thread overview]
Message-ID: <481810B7.90000@pajato.com> (raw)
In-Reply-To: <4817D79F.8040508@gmail.com>
Stephen Eilert wrote:
> Richard M Stallman wrote:
>> The other hard problem is multi-tasking in the Emacs Lisp engine.
>> RMS once left me with the impression that this was virtually
>> intractable, especially if one wanted to have existing Elisp code
>> base
>> compatibility, a reasonable thing to want.
>>
>> I think "intractable" might be too pessimistic. It is certainly
>> a lot of work, but someone could give it a try.
>>
>>
>>
> Before diving in the merits of whether or not it is possible to add
> multi-tasking to Emacs (by that I assume full-blown threads), what are
> the problems this is trying to solve?
>
> Is it to add background processing (as in, file indexing, background
> compilation, downloads and the like)? If then, a notion of task
> priorities could be discussed. For instance, Eclipse knows that, in
> order to deploy an application, it must be compiled first. It
> understands that those tasks cannot happen in parallel and should be
> queued. On the other hand, you can start downloads (usually, plugins and
> updates for said plugins) right away.
>
> It could be a way to use the increasing amount of available processing
> cores in personal computers. Then again, Emacs doesn't seem like a
> particularly CPU-bound application.
>
> So I am at a loss why this is so important. Could someone clarify?
Over the years I've frequently encountered situations where I started
executing some Elisp code that took longer than I expected. Things like
rgrepping and accessing the network where the network issues have Emacs'
dedicated attention (and probably some more examples if I paid more
close attention). My first inclination was to start up another instance
of Emacs and that was cool --- I now typically use half a dozen
instances at any one time --- but it did occur to me that I was
essentially running another Elisp engine, i.e. another thread. So that
was basically the reason why I had the conversation with Richard in the
first place. Much as I'd love to have multi-threading in Emacs it is
way over my head, at least in any kind of reasonable timeframe. Now
fast forward to the era of multiple tabbed browsing, mostly firefox.
Each tab is essentially a separate thread so if the holy grail of
marrying multi-site browsing and Emacs is to be obtained some form of
multi-threading seems intuitively required. But if some wizard figures
out how to get the grail with only a half a thread, that works for me. :-)
I think the main point is that those of us who feel annoyed every time
we have to leave an Emacs frame to do some work can only get
satisfaction from Emacs when it can do multiple of those things that now
cause it prevent the User from doing something else inside of Emacs
while it is cranking where it really doesn't matter whether the cranking
is on the CPU(s) or in the I/O.
-pmr
next prev parent reply other threads:[~2008-04-30 6:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 3:19 Very interesting analysis of "the state of Emacs" Thomas Lord
2008-04-29 7:26 ` Paul Michael Reilly
2008-04-29 23:17 ` Richard M Stallman
2008-04-30 0:14 ` Thomas Lord
2008-04-30 2:21 ` Stephen Eilert
2008-04-30 3:20 ` dhruva
2008-04-30 22:00 ` Richard M Stallman
2008-04-30 22:49 ` David Hansen
2008-04-30 23:46 ` Thomas Lord
2008-05-01 7:30 ` tomas
2008-05-01 4:23 ` Jonathan Rockway
2008-05-01 6:31 ` David Hansen
2008-05-01 6:42 ` Miles Bader
2008-05-01 18:59 ` Jonathan Rockway
2008-05-02 15:36 ` Stefan Monnier
2008-05-02 16:50 ` CEDET and threads (was Re: Very interesting analysis of "the state of Emacs") Eric M. Ludlam
2008-05-03 8:09 ` Very interesting analysis of "the state of Emacs" Richard M Stallman
2008-05-03 19:24 ` Stefan Monnier
2008-05-04 9:37 ` Richard M Stallman
2008-05-04 23:23 ` buffer transactions (was Re: Very interesting analysis of "the state of Emacs") Nic
2008-05-05 15:14 ` Richard M Stallman
2008-04-30 5:12 ` Very interesting analysis of "the state of Emacs" Miles Bader
2008-04-30 14:06 ` David Kastrup
2008-04-30 15:08 ` Tom Tromey
2008-05-15 6:21 ` ERC disconnects when blocked too long (was: Very interesting analysis of "the state of Emacs") Michael Olson
2008-04-30 16:08 ` Very interesting analysis of "the state of Emacs" Thomas Lord
2008-04-30 6:24 ` Paul Michael Reilly [this message]
2008-04-30 14:12 ` Mathias Dahl
2008-04-30 22:01 ` Richard M Stallman
2008-04-30 22:56 ` Thomas Lord
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=481810B7.90000@pajato.com \
--to=pmr@pajato.com \
--cc=emacs-devel@gnu.org \
--cc=spedrosa@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).