[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: |
Richard M Stallman |
Subject: |
Re: Very interesting analysis of "the state of Emacs" |
Date: |
Sun, 04 May 2008 05:37:53 -0400 |
Good point. But I don't think it's a problem either: what I meant by
"multithreading within a single buffer" is that we'd have a lock per
buffer. Whenever lisp code enters a buffer, we'd acquire the lock.
What does it mean to "enter a buffer"? Does calling `set-buffer' do
that?
If it means entering the code of a primitive that directly examines or
alters the buffer contents, I would suggest not allowing a thread
switch inside of them (or most primitives). If the threads are
implemented explicitly in our C code, switching can happen only where
we want it to happen. That would avoid lots of problems. We would
only allow thread switches at places where Lisp code can be run.
- Re: Very interesting analysis of "the state of Emacs", Jonathan Rockway, 2008/05/01
- Re: Very interesting analysis of "the state of Emacs", David Hansen, 2008/05/01
- Re: Very interesting analysis of "the state of Emacs", Miles Bader, 2008/05/01
- Re: Very interesting analysis of "the state of Emacs", Jonathan Rockway, 2008/05/01
- Re: Very interesting analysis of "the state of Emacs", Stefan Monnier, 2008/05/02
- CEDET and threads (was Re: Very interesting analysis of "the state of Emacs"), Eric M. Ludlam, 2008/05/02
- Re: Very interesting analysis of "the state of Emacs", Richard M Stallman, 2008/05/03
- Re: Very interesting analysis of "the state of Emacs", Stefan Monnier, 2008/05/03
- Re: Very interesting analysis of "the state of Emacs",
Richard M Stallman <=
- buffer transactions (was Re: Very interesting analysis of "the state of Emacs"), Nic, 2008/05/04
- Re: buffer transactions (was Re: Very interesting analysis of "the state of Emacs"), Richard M Stallman, 2008/05/05