all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Emacs development discussions <emacs-devel@gnu.org>
Subject: advice needed for multi-threading patch
Date: Tue, 25 Aug 2009 22:38:41 -0600	[thread overview]
Message-ID: <m3eiqz2nqm.fsf@fleche.redhat.com> (raw)

I was inspired by Giuseppe Scrivano's work from last year:

http://lists.gnu.org/archive/html/emacs-devel/2008-11/msg01067.html

... so I started working on my own patch to implement multi-threading in
Emacs.  I've tried to follow Stefan's advice as given in that thread.
In particular I've (initially) implemented cooperative multi-threading.

Some background for my particular question:

My implementation of dynamic binding uses a structure like so:

    struct Lisp_ThreadLocal
      {
        enum Lisp_Misc_Type type : 16;	/* = Lisp_Misc_ThreadLocal */
        unsigned gcmarkbit : 1;
        int spacer : 15;
        Lisp_Object global;
        Lisp_Object thread_alist;
      };

... the idea being that a let-bound variable will be on 'thread_alist'
(keyed by the thread), and other threads will see the value in 'global'.
These objects are found in symbol value slots.

I managed to handle the V* global variables by writing some elisp that
changed every declaration of a variable mentioned in a DEFVAR_LISP from
Vfoo to impl_Vfoo and also emitted a new header with a lot of:

    #define Vfoo *find_variable_location (&impl_Vfoo)

This was pretty simple and non-intrusive, in the sense that it is
totally automated, so I can easily reapply it as Emacs changes.

... which brings me to my problem.  I'd also like to apply a similar
treatment to buffer-local variables.  However, those do not have
convenient accessor macros, and before starting the laborious task of
wrapping all buffer field accesses, I thought I'd ask for advice.  Is
this a sane way to proceed?  Should I do something different?  Could I
get such a patch in before the rest of this work, just to make my local
divergence smaller?

I'll also note that the above approach does not work for DEFVAR_INT.  I
have a plan for those but I fear it is somewhat expensive.  If you have
an idea...

Tom




             reply	other threads:[~2009-08-26  4:38 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-26  4:38 Tom Tromey [this message]
2009-08-26  7:06 ` advice needed for multi-threading patch 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
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=m3eiqz2nqm.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=emacs-devel@gnu.org \
    /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.