From: Jonathan Rockway <jon@jrock.us>
To: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Very interesting analysis of "the state of Emacs"
Date: Thu, 01 May 2008 13:59:21 -0500 [thread overview]
Message-ID: <87prs5n94m.fsf@bar.jrock.us> (raw)
In-Reply-To: <87od7qikyc.fsf@catnip.gol.com> (Miles Bader's message of "Thu, 01 May 2008 15:42:51 +0900")
* On Thu, May 01 2008, Miles Bader wrote:
> Jonathan Rockway <jon@jrock.us> writes:
>> The issue is when we start putting global variables into the mix:
> ...
>> Anyway, hopefully someone has some ideas on what to do here. I admit I
>> haven't looked at how sxemacs handles this yet. Maybe we can just deal
>> with locks? At least in that case my IMAP mail could download while I
>> am typing in another buffer :)
>
> If the multi-threading were cooperative (as rms suggested), then such
> problems would obviously be a bit easier to manage -- you can basically
> just say "no context switches except at well defined points", and define
> these "points" to be (1) user interaction/recursive edits [where the
> user can do something to "screw up the state" even today], or (2)
> explicit calls to yield.
Yeah, thinking about this some more, I definitely agree with you. 99.9%
of emacs works fine the way it is, so this seems like the cleanest way
to make long operations not block.
I don't know the emacs core well enough to start implementing this, but
I would be glad to help out if someone else takes the lead. :)
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"
next prev parent reply other threads:[~2008-05-01 18:59 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87prs5n94m.fsf@bar.jrock.us \
--to=jon@jrock.us \
--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.