[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: advice needed for multi-threading patch
From: |
Stefan Monnier |
Subject: |
Re: advice needed for multi-threading patch |
Date: |
Mon, 21 Sep 2009 17:19:42 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
> * Many, but not all, of the 9 kinds of variables that Emacs implements
> work properly with threads. In particular, working ones are
> defvaralias, objfwd, and ordinary. These all should do the right
> thing in all cases. Buffer-local and buffer objfwd mostly work,
> because we do buffer locking. (However, I think make-local-variable
> doesn't work properly with let-binding and multiple threads.) Not
> working on intfwd, boolfwd, keyboard-local and frame-local.
How do you handle objfwd objects? Do you swap them in&out during
context switches?
> * Buffer locking is actually quite a pain.
> If you have a background thread locking some buffer, you can't switch
> to that buffer. Emacs will just pause. I don't think we allow
> interrupting a lock acquisition (clearly a bug).
Yes, we may have to relax the locking somehow. E.g. we should clearly
allow to display a buffer in any window, if the buffer is "locked" by
a thread. I.e. things like switch-to-buffer should not take the
buffer's lock.
Of course, if the buffer is locked by a thread, we also need to be
careful what we do if the user then types a command in it (should we
wait for the thread to yield or should we signal an erreur?)
> * Giuseppe implemented minibuffer exclusion. But really the keyboard
> should only be available to one thread at a time.
You mean "each keyboard", right?
> Also, there are tons more problems if you want preemptive
> multithreading... redisplay probably needs work, regex is not
> reentrant, the GC needs a bit more work, you need lisp-level
> locks, etc.
Yes, lots of fun stuff, indeed.
> Sometimes I wonder whether it would be better to just fork a second
> emacs and communicate with it using pipes + princ + read. This uses
> more memory but the implementation would be a lot simpler and (I think)
> it would suffice for the one case that seems most important: Gnus.
But you can already do that right now, so it's a different "solution".
Stefan
- Re: advice needed for multi-threading patch, Tom Tromey, 2009/09/18
- Re: advice needed for multi-threading patch, Stephen J. Turnbull, 2009/09/18
- Re: advice needed for multi-threading patch, Chong Yidong, 2009/09/18
- Re: advice needed for multi-threading patch,
Stefan Monnier <=
- Re: advice needed for multi-threading patch, Tom Tromey, 2009/09/21
- Re: advice needed for multi-threading patch, Tom Tromey, 2009/09/22
- Re: advice needed for multi-threading patch, Stefan Monnier, 2009/09/24
- Re: advice needed for multi-threading patch, Tom Tromey, 2009/09/24
- Re: advice needed for multi-threading patch, Tom Tromey, 2009/09/27
- Re: advice needed for multi-threading patch, Stefan Monnier, 2009/09/27