all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Ken Raeburn <raeburn@raeburn.org>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: advice needed for multi-threading patch
Date: Wed, 26 Aug 2009 10:08:01 -0600	[thread overview]
Message-ID: <m3r5uy1rtq.fsf@fleche.redhat.com> (raw)
In-Reply-To: <B512513D-5F4A-43A7-BE6F-57B38331992E@raeburn.org> (Ken Raeburn's message of "Wed, 26 Aug 2009 03:06:38 -0400")

>>>>> "Ken" == Ken Raeburn <raeburn@raeburn.org> writes:

Ken> I hope you and Daniel and I aren't doing redundant work.

Unless your changes apply to Emacs I don't think they are really
redundant.  I think the key thing is agree how it ought to work, so we
end up with the same model, but I don't anticipate any problems there.

Ken> I've written similar elisp code for doing transformations of patterns
Ken> within the Emacs code -- mostly more localized things like "XCONS
Ken> (expr)->car" to "XCAR (expr)", but with support for somewhat complex
Ken> values of "expr" that have to have balanced parens, etc.

If you still have these, I would appreciate a copy, so that I don't have
to reinvent them.  Are they in your git repository?

Ken> I wonder if anyone's looking at collecting elisp tools for C
Ken> refactoring somewhere.

There may be some on the CEDET site.  I don't remember seeing any on the
wiki or elsewhere.

Ken> Should I take this to mean you've already dealt with the buffer-local
Ken> variables created by make-variable-buffer-local, which don't live in
Ken> the buffer structure?

Well... nominally.  It is still a buggy mess.

Ken> If so, I wonder if you can make use of those
Ken> changes, by replacing XBUFFER(b)->thing with SYMBOL_VALUE(Qthing)
Ken> where Qthing holds a symbol that's marked as buffer-local; then all
Ken> the changes for the interaction between thread-local and buffer-local
Ken> bindings would be localized in indirect_variable and friends, which
Ken> would then have to deal with both Lisp_Misc_Buffer_Objfwd and
Ken> Lisp_Misc_Buffer_Local_Value.

I will have to think about this.  This would imply removing all those
slots from struct buffer; I suppose my concern would be that the result
would be too inefficient.

I've also been considering a similar thing for the Vfoo globals: remove
them and have the C code always refer to them via SYMBOL_VALUE.

Tom




  parent reply	other threads:[~2009-08-26 16:08 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 [this message]
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=m3r5uy1rtq.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=emacs-devel@gnu.org \
    --cc=raeburn@raeburn.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.