[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-threaded Emacs
From: |
Giuseppe Scrivano |
Subject: |
Re: multi-threaded Emacs |
Date: |
Sat, 29 Nov 2008 22:01:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Hello,
Stefan Monnier <address@hidden> writes:
> - handling thread-specific data: gcprolist, mark_byte_stack, and things
> like that. You've tackled this one. I don't find your solution very
> elegant, but I can't think of a much better one, unless pthreads does
> provide some kind of thread-specific variables. I guess the only
> improvement is to put those vars together, so we have an array of
> structs (that then contain gcprolist, and mark_byte_stack fields)
> rather than several arrays. And then define `gcprolist' as a macro
> that expands into "thread_data[current_thread()].gcprolist", so as to
> reduce the amount of source-code changes.
Yes, we can put thread-specific data together in a struct; what about
buffer data? `current_buffer' must be different for every thread so as
many other global variables, should it be defined in the same
thread_data struct?
> - dynamic-scoping: your handling of specpdl is naive and
> fundamentally flawed. For multithreading, we will have to completely
> change the implementation technique of dynamic-scoping.
I know but it was the easier way to have quickly a working
proof-of-concept as I concentrated my efforts mainly on the syntax.
Do you have any idea about how dynamic scoping should be handled in a
multi-threaded environment?
> - synchronization to access all the global variables/objects.
> You haven't yet have time to tackle this (other than in `put', it
> seems), and it's going to be difficult.
Why do you think that a global lock (or several ones for separate kind
of data) will not be enough? It is not easy but I think it can be done
in a reasonable time without many troubles.
> - concurrent GC (later to be refined to parallel concurrent GC ;-).
>
> - redisplay in its own thread (later to be refined to one redisplay
> thread per terminal, then per frame, then per window ;-).
I think that this is the most difficult part, a new GC and how handle
redisplay.
Different threads can use the same buffer and a buffer can have no
threads actually using it. I would simplify this part, maybe leave the
redisplay task only to a thread.
> A first step will be to restrict the implementation such that there's no
> parallelism: only one thread executes at any given time (i.e. have
> a single lock and have all thread grab the lock before doing any actual
> work).
IMHO it is better to avoid this middle solution and try to solve
directly the problem, it will not give real benefits and having only one
thread executes at a given time can be done differently, like saving and
restoring the thread call stack. Real threads will not suffer I/O bound
operations and Emacs will be able to use more cores at the same time, if
needed.
Thanks,
Giuseppe
- multi-threaded Emacs, Giuseppe Scrivano, 2008/11/29
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/29
- Re: multi-threaded Emacs,
Giuseppe Scrivano <=
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/29
- Re: multi-threaded Emacs, Giuseppe Scrivano, 2008/11/30
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/30
- Re: multi-threaded Emacs, Giuseppe Scrivano, 2008/11/30
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/30
- Re: multi-threaded Emacs, Giuseppe Scrivano, 2008/11/30
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/30
Re: multi-threaded Emacs, Tom Tromey, 2008/11/29
Re: multi-threaded Emacs, Richard M Stallman, 2008/11/30