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. :)
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"