From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Tom Tromey <tromey@redhat.com>, Chong Yidong <cyd@gnu.org>,
12215@debbugs.gnu.org, Dmitry Antipov <dmantipov@yandex.ru>
Subject: bug#12215: CSET is unnecessarily confusing
Date: Fri, 24 Aug 2012 10:19:34 -0700 [thread overview]
Message-ID: <5037B7A6.5030202@cs.ucla.edu> (raw)
In-Reply-To: <jwvd32gs5ay.fsf-monnier+emacs@gnu.org>
[Tom, I'm CC'ing you as this discussion is veering into concurrency.
For context please see <http://bugs.gnu.org/12215#34>.]
On 08/24/2012 08:10 AM, Stefan Monnier wrote:
> The BVAR accessor macro is not for the GC but for the concurrency code.
How exactly does that work? I just now looked at the concurrency branch
and its BVAR is the same as in the trunk.
Is BVAR a speculative change, that was put in because eventually we
thought we'd need it for concurrency? If so, perhaps we should revert
it until the need is demonstrated. After all, it's been many months
since BVAR went in, and the concurrency branch still isn't really
using it.
> And yes, I think that BVAR(foo->bar) can be sufficient for the
> concurrency code (it can be macro-expanded to buffer_var(foo->bar,
> current_thread)), assuming we change all buffer slots to be of a new
> type, which is a table from thread_ids to Lisp_Object.
In that case we shouldn't need BVAR. Instead, we can do something
like this:
#define backed_up backed_up_table[current_thread->id]
#define save_length save_length_table[current_thread->id]
...
and then instead of this:
bset_save_length (b, Fadd1 (BVAR (b, save_length)));
code can just go back to what it used to do:
b->save_length = Fadd1 (b->save_length);
which is considerably more readable.
If you like, we could use a different naming convention for
these special slots, to give the reader a clue that the slots
are actually thread-local. But the point is that we shouldn't
need BVAR or BSET.
> For the setters, I think we'll be better off with either
> BSET (b->directory, val), or BSET (b, ->directory, val), which restricts
> the form that can be used.
Wouldn't the above approach work for setters too?
The concurrency branch's BSET macro is also identical to that
of the trunk, so it's hard to see what the plan is here ...
next prev parent reply other threads:[~2012-08-24 17:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-17 0:04 bug#12215: CSET is unnecessarily confusing Paul Eggert
2012-08-17 4:12 ` Dmitry Antipov
2012-08-21 16:55 ` Stefan Monnier
2012-08-22 3:25 ` Paul Eggert
2012-08-22 13:27 ` Stefan Monnier
2012-08-22 16:35 ` Paul Eggert
2012-08-22 16:50 ` Dmitry Antipov
2012-08-23 7:02 ` Paul Eggert
2012-08-23 12:26 ` Stefan Monnier
2012-08-23 14:40 ` Paul Eggert
2012-08-24 3:46 ` Chong Yidong
2012-08-24 3:57 ` Paul Eggert
2012-08-24 4:26 ` Dmitry Antipov
2012-08-24 15:10 ` Stefan Monnier
2012-08-24 17:19 ` Paul Eggert [this message]
2012-08-24 17:27 ` Tom Tromey
2012-08-24 18:11 ` Paul Eggert
2012-08-24 21:12 ` Stefan Monnier
2012-08-25 0:17 ` Paul Eggert
2012-08-25 1:58 ` Stefan Monnier
2012-08-26 5:05 ` Paul Eggert
2012-08-21 17:55 ` Stefan Monnier
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=5037B7A6.5030202@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=12215@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=dmantipov@yandex.ru \
--cc=monnier@iro.umontreal.ca \
--cc=tromey@redhat.com \
/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.