[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Very interesting analysis of "the state of Emacs"

From: Jonathan Rockway
Subject: Re: Very interesting analysis of "the state of Emacs"
Date: Thu, 01 May 2008 13:59:21 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

* On Thu, May 01 2008, Miles Bader wrote:
> Jonathan Rockway <address@hidden> 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. :)

Jonathan Rockway

print just => another => perl => hacker => if $,=$"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]