bug#12215: CSET is unnecessarily confusing

[Paul Eggert <eggert@cs.ucla.edu>]

[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 ...