As I understand it such an implementation would not take advantage of
the new hardware that supports multi-threading, eg: multi-core x86
processors.
I am not sure that case is important, or that it would outweigh
the slowness of all variable accesses.
I don't think that Emacs will oft
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> That would make the usual case much slower.
> I prefer the idea of swapping bindings on thread switches.
As I understand it such an implementation would not take advantage of
the new hardware that supports multi-threading, eg: multi-core x86
pro
If the secondary thread modifies a global, make the copy then (Copy On
Write).
This would be difficult to implement, considering that a symbol's value
is normally kept in its value cell.
The interpreter would just have to keep a hashtable of hashtables;
primary key is the secondar
Nic Ferrier wrote:
I think threads would be most useful for things like fontification and
parsing (eg: in xml buffers).
nxml-mode works pretty well for parsing and fontifying xml.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.
On Mon, 20 Jun 2005, [EMAIL PROTECTED] wrote:
> Do you know of any applications that require this? For many purposes,
> using timers etc. seems to work fairly well already.
Gnus summary threading and spam processing, for example, could benefit
greatly from multi-threading. It does not require i
On Fri, 17 Jun 2005, [EMAIL PROTECTED] wrote:
> I'm thinking of ways to avoid the stack penalties the other proposals
> involve. Could we allow only secondary threads with thread-local
> variables and forked copies of globals?
>
> "Forked copies of globals" would mean copies of the v
David Kastrup <[EMAIL PROTECTED]> writes:
> And that's what multithreading is about: making conceptually easy
> tasks easy to code. Not merely making them possible to code: you can
> always hardcode the inner state maintained by the combination of a
> stack and the program counter.
>
> But it is
Nic Ferrier <[EMAIL PROTECTED]> writes:
> Miles Bader <[EMAIL PROTECTED]> writes:
>
>> On 6/17/05, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
>>> This will make threads more of a utility than a true built-in, and
>>> threaded code would be written especially for that purpose.
>>
>> Do you know of any
Miles Bader <[EMAIL PROTECTED]> writes:
> On 6/17/05, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
>> This will make threads more of a utility than a true built-in, and
>> threaded code would be written especially for that purpose.
>
> Do you know of any applications that require this? For many purpos
On 6/17/05, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> This will make threads more of a utility than a true built-in, and
> threaded code would be written especially for that purpose.
Do you know of any applications that require this? For many purposes,
using timers etc. seems to work fairly well
I'm thinking of ways to avoid the stack penalties the other proposals
involve. Could we allow only secondary threads with thread-local
variables and forked copies of globals?
"Forked copies of globals" would mean copies of the values of
thousands of Lisp symbols. And how would the Li
On Fri, 17 Jun 2005, [EMAIL PROTECTED] wrote:
> A huge amount of the actively maintained state in Emacs is stored in
> global variables (often buffer-local of course, but still "global"
> as far as threads are concerned).
Thank you for the clarification.
I'm thinking of ways to avoid the stack p
On 6/17/05, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> > This is not really true for typical elisp programs -- global variables
> > (especially buffer-local global variables) are used extremely often,
> > and in almost every case must be "truly global" (visible in all
> > threads).
>
> At the time
On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote:
On 6/16/05, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
>> I'm not sure I understand the problem. Do you mean that if a user
>> changes variable A in thread 1, he expects thread 2 to also notice the
>> change for certain global variables? That's easy to
On 6/16/05, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> I'm not sure I understand the problem. Do you mean that if a user
> changes variable A in thread 1, he expects thread 2 to also notice the
> change for certain global variables? That's easy to do, if you
> consider that such global variables a
On Sat, 11 Jun 2005, [EMAIL PROTECTED] wrote:
> I think an alternate solution is to have no shared variables between
> threads once they are forked, and communicate through standard IPC
> (pipes, semaphores, etc.).
>
> This is not possible with shallow binding. All Lisp programs
> us
I think an alternate solution is to have no shared variables between
threads once they are forked, and communicate through standard IPC
(pipes, semaphores, etc.).
This is not possible with shallow binding. All Lisp programs
use the same set of symbols, and each symbol has a value.
Man
> I think an alternate solution is to have no shared variables between
> threads once they are forked, and communicate through standard IPC
> (pipes, semaphores, etc.).
Interesting.
I have never imaged this idea.
How do you think linda instead of the standard IPC.
http://heather.cs.ucdavis.edu/~
On Thu, 09 Jun 2005, [EMAIL PROTECTED] wrote:
> The greatest obstacle to this seems to be shallow binding - you'd have
> to unwind one thread's stack and rewind another's when switching
> threads. Maybe there's an easier way that I don't see...
>
> That is how the Lisp Machine worked
Something that would help a great deal is if one could create a buffer
that was hidden, ie: it did not ordinarily appear in the buffer list
and was not returned by a call to:
(get-buffer buffername)
Why do you think this is necessary?
I don't see what problem this would solve.
The greatest obstacle to this seems to be shallow binding - you'd have
to unwind one thread's stack and rewind another's when switching
threads. Maybe there's an easier way that I don't see...
That is how the Lisp Machine worked. It is not an unreasonable idea.
> We don't need threads in elisp. Just more asynchronous network
> implementations.
Multiple threads are the only way to make the support for
multiple terminals in a single Emacs process really work right.
I am not sure to what extent full support for multiple terminals is
really useful i
It will be better if someone pick up guile-emacs works. Guile is
multithreaded and async IO. To bad that work is not going fast enough.
steve
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
On 6/9/05, Nic Ferrier <[EMAIL PROTECTED]> wrote:
> Something that would help a great deal is if one could create a buffer
> that was hidden, ie: it did not ordinarily appear in the buffer list
> and was not returned by a call to:
>
> (get-buffer buffername)
Why?
The goal of not annoying use
> I think elisp is always going to need a huge amount of blocking to use
> OS threads because of the nature of dynamic scope.
I expect that making cooperative threads work (with context switches only at
those places where we currently allow running things like timers and process
filters), is curre
Related to the discussion about threads is the issue of making
asycnhronous network programming in emacs easier.
I wrote an article on how I tried and failed (for now) to write a good
async IMAP library in elisp:
http://www.tapsellferrier.co.uk/nics-articles/imapua-failure.html
One of the thi
Magnus Henoch <[EMAIL PROTECTED]> writes:
> Nic Ferrier <[EMAIL PROTECTED]> writes:
>
>> We don't need threads in elisp. Just more asynchronous network
>> implementations.
>
> Good point.
>
> What is the best way to send a large amount of data to a network
> connection in the background? You coul
Nic Ferrier <[EMAIL PROTECTED]> writes:
> We don't need threads in elisp. Just more asynchronous network
> implementations.
Good point.
What is the best way to send a large amount of data to a network
connection in the background? You could send a chunk at a time with
process-send-string and th
jhd <[EMAIL PROTECTED]> writes:
>>> The greatest obstacle to this seems to be shallow binding - you'd
>>> have
>>> to unwind one thread's stack and rewind another's when switching
>>> threads. Maybe there's an easier way that I don't see...
>>>
>>
>> I don't see why this subject keeps coming up
The greatest obstacle to this seems to be shallow binding - you'd
have
to unwind one thread's stack and rewind another's when switching
threads. Maybe there's an easier way that I don't see...
I don't see why this subject keeps coming up.
We don't need threads in elisp. Just more asynchrono
Magnus Henoch <[EMAIL PROTECTED]> writes:
> I've been thinking about using GNU pth to implement threads in Emacs.
> GNU pth only does cooperative threading, and has special non-blocking
> versions of some syscalls (blocking the current thread instead of the
> whole process). Ideally this would me
I've been thinking about using GNU pth to implement threads in Emacs.
GNU pth only does cooperative threading, and has special non-blocking
versions of some syscalls (blocking the current thread instead of the
whole process). Ideally this would mean that existing
(i.e. non-yielding) Lisp code woul
Garbage collection also gets more interesting when
multiple threads are manipulating Lisp objects at a time.
In Emacs, GC doesn't have to happen at any particular point.
It is done as a regular housekeeping task.
So it could work well enough to set a flag telling all threads to wait
on
Nic Ferrier writes:
> A couple of times I've thought about just linking guile and emacs
> together, giving guile some wrappers around existing emacs types and
> adding some mechanism to emacs for running guile programs.
There was a working prototype a couple of years ago by Keisuke Nishida
(of G
Ken Raeburn <[EMAIL PROTECTED]> writes:
> For various reasons, I decided to put my attention about three years or
> so ago into a somewhat different project -- making it possible to run
> Emacs with the Guile interpreter tied into the Lisp system. Guile --
> GNU's Ubiquitous Intelligent Langua
On Jun 6, 2005, at 22:22, Denis Bueno wrote:
Having said that, my question is, has thought been put into
multithreading parts of Emacs? Or exposing a rudimentary threading API
to Emacs Lisp? This could easily devolve into a war about threading
apis, but, just support some simple subset of pthread
Denis Bueno <[EMAIL PROTECTED]> writes:
> I tried that, but, searching for 'thread' in a huge database of
> mailing list 'threads' is not as useful as one might think. =]
>
> Is there one conversation in particular you are thinking of?
Yes; the following Google search yields many good first-page h
On 6/6/05, Miles Bader <[EMAIL PROTECTED]> wrote:
> On 6/7/05, Denis Bueno <[EMAIL PROTECTED]> wrote:
> > Having said that, my question is, has thought been put into
> > multithreading parts of Emacs?
>
> Yes. It's very hard, because Emacs has lots and lots of global state
> and lots and lots of
On 6/7/05, Denis Bueno <[EMAIL PROTECTED]> wrote:
> Having said that, my question is, has thought been put into
> multithreading parts of Emacs?
Yes. It's very hard, because Emacs has lots and lots of global state
and lots and lots of code that doesn't expect to deal with threading
issues. Writi
39 matches
Mail list logo
