From: Tom Tromey <tromey@redhat.com>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: advice needed for multi-threading patch
Date: Mon, 21 Sep 2009 15:50:32 -0600 [thread overview]
Message-ID: <m3k4zsx907.fsf@fleche.redhat.com> (raw)
In-Reply-To: <jwvfxagq9wv.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 21 Sep 2009 17:19:42 -0400")
>>>>> "Stefan" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
Tom> * Many, but not all, of the 9 kinds of variables that Emacs implements
Tom> work properly with threads. In particular, working ones are
Tom> defvaralias, objfwd, and ordinary. These all should do the right
Tom> thing in all cases. Buffer-local and buffer objfwd mostly work,
Tom> because we do buffer locking. (However, I think make-local-variable
Tom> doesn't work properly with let-binding and multiple threads.) Not
Tom> working on intfwd, boolfwd, keyboard-local and frame-local.
Stefan> How do you handle objfwd objects? Do you swap them in&out during
Stefan> context switches?
We have a script to edit the Emacs source. In the end all DEFUN_LISP
variables are defined like:
#define Vafter_change_functions *find_variable_location (&impl_Vafter_change_functions)
Then, find_variable_location understands Lisp_ThreadLocal binding.
A Lisp_ThreadLocal is put into an impl_V* by specbind.
This works great as long as the C code follows lispy rules. However, I
don't think that is always the case -- there are places doing direct
assignment to some of these variables where, really, a per-thread
assignment is meant.
We don't swap anything in and out during a context switch. I've tried
to make all the decisions with an eye on the long term: preemptive
threading. Ultimately I'd like to get rid of the global lock and have
all threads run free.
Tom> * Buffer locking is actually quite a pain.
Tom> If you have a background thread locking some buffer, you can't switch
Tom> to that buffer. Emacs will just pause. I don't think we allow
Tom> interrupting a lock acquisition (clearly a bug).
Stefan> Yes, we may have to relax the locking somehow. E.g. we should clearly
Stefan> allow to display a buffer in any window, if the buffer is "locked" by
Stefan> a thread. I.e. things like switch-to-buffer should not take the
Stefan> buffer's lock.
Stefan> Of course, if the buffer is locked by a thread, we also need to be
Stefan> careful what we do if the user then types a command in it (should we
Stefan> wait for the thread to yield or should we signal an erreur?)
Giuseppe has some code to let a thread acquire a buffer without locking.
But, this is done in an unsafe way; I think it is just a hack to let him
experiment with Gnus a bit.
Right now when a thread yields it does not release its buffer lock.
The only way to do that is to set-buffer to another buffer.
One way forward would be to work out the semantics properly, and
eliminate buffer locking. Some of the semantics seems tricky. And, the
work itself is hard, because it means adding tons of accessor macros and
then updating a lot of source code to use them. (I did this, once, for
a lot of Emacs, thinking to implement a software write barrier. It is
really quite painful.)
Tom> * Giuseppe implemented minibuffer exclusion. But really the keyboard
Tom> should only be available to one thread at a time.
Stefan> You mean "each keyboard", right?
Yes.
Locking a keyboard will probably have strange effects. There are some
things here that I have not thought through; like, what is the right
behavior of debug-on-error? Under what conditions would the main thread
ever release the keyboard?
Tom> Sometimes I wonder whether it would be better to just fork a second
Tom> emacs and communicate with it using pipes + princ + read. This uses
Tom> more memory but the implementation would be a lot simpler and (I think)
Tom> it would suffice for the one case that seems most important: Gnus.
Stefan> But you can already do that right now, so it's a different "solution".
Yeah. I just wonder why nobody has done it and whether it would not be
a better approach.
Tom
next prev parent reply other threads:[~2009-09-21 21:50 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 4:38 advice needed for multi-threading patch Tom Tromey
2009-08-26 7:06 ` Ken Raeburn
2009-08-26 14:52 ` Stefan Monnier
2009-08-26 18:50 ` Ken Raeburn
2009-08-27 3:12 ` Stefan Monnier
2009-08-27 6:28 ` Ken Raeburn
2009-08-27 17:02 ` Stefan Monnier
2009-08-26 16:08 ` Tom Tromey
2009-08-26 18:50 ` Ken Raeburn
2009-08-27 5:07 ` Miles Bader
2009-08-27 6:39 ` Ken Raeburn
2009-08-27 6:50 ` Miles Bader
2009-08-28 20:48 ` Juri Linkov
2009-08-28 22:15 ` Miles Bader
2009-08-28 23:27 ` Juri Linkov
2009-08-28 23:54 ` Miles Bader
2009-08-29 20:21 ` Richard Stallman
2009-08-26 15:02 ` Stefan Monnier
2009-08-26 15:31 ` Tom Tromey
2009-08-26 19:18 ` Stefan Monnier
2009-09-18 22:59 ` Tom Tromey
2009-09-19 0:09 ` Stephen J. Turnbull
2009-09-19 0:32 ` Chong Yidong
2009-09-21 21:19 ` Stefan Monnier
2009-09-21 21:50 ` Tom Tromey [this message]
2009-09-22 14:24 ` Stefan Monnier
2009-09-22 23:59 ` Ken Raeburn
2009-09-23 3:11 ` Stefan Monnier
2009-09-23 15:53 ` Chong Yidong
2009-09-23 3:16 ` Tom Tromey
2009-09-24 17:25 ` Stefan Monnier
2009-09-24 17:57 ` Tom Tromey
2009-09-27 20:59 ` Tom Tromey
2009-09-27 23:05 ` Stefan Monnier
2009-09-28 4:27 ` Tom Tromey
2009-09-29 0:27 ` Stefan Monnier
2009-09-29 2:26 ` Ken Raeburn
2009-09-29 3:20 ` Stefan Monnier
2009-09-29 3:57 ` Ken Raeburn
2009-09-29 3:33 ` Tom Tromey
2009-09-29 4:07 ` Ken Raeburn
2009-09-29 2:30 ` Tom Tromey
2009-09-23 18:43 ` Giuseppe Scrivano
2009-09-24 17:29 ` Stefan Monnier
2009-09-24 18:53 ` Giuseppe Scrivano
2009-09-24 20:04 ` Tom Tromey
2009-09-24 21:59 ` Stefan Monnier
2009-09-24 22:23 ` Giuseppe Scrivano
2009-09-24 22:47 ` Ken Raeburn
2009-09-28 14:52 ` Ted Zlatanov
2009-10-05 6:02 ` joakim
2009-09-28 7:44 ` Lynbech Christian
2009-08-29 0:28 ` Giuseppe Scrivano
2009-08-29 4:57 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3k4zsx907.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.