[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The rest of xVARs
From: |
Dmitry Antipov |
Subject: |
Re: The rest of xVARs |
Date: |
Thu, 09 Aug 2012 10:14:27 +0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
On 08/08/2012 12:30 AM, Stefan Monnier wrote:
Should we also try to get rid of INTERNAL_FIELD, (B|K)VARs
but provide (B|K)SET macros similar to (F|W)SET?
BVAR and KVAR were introduced for a different need: these fields are
exported as Lisp vars, so they can be let-bound, and in the concurrency
branch this will require special treatment both for reads and for writes
(basically, while it's a single field, it can contain various values:
one per thread).
We're very, very far from the full-featured Lisp threads; for me, even
a new GC looks simpler and more realistic :-). (I don't believe that we
will have multithreaded buffer processing in the foreseeable future,
but rather believe in a kind of implicit, i.e. invisible for Lisp,
concurrency like thread-per-buffer (sometimes) or thread-per-frame).
I can't continue without solving (B|K)VARs issue, and X = B->field/
BSET(B, field, X) is enough for my purposes; so I'm voting for doing
it so unless there is a plan to merge something from the concurrency
branch which can conflict with this. IIUC, real support for per-thread
values is not ever designed anyway.
I dislike the current BVAR/KVAR mostly because it receives a field name
as parameter (so it looks like a variable, while it's only a field
name). Maybe we can use TGET (foo->bar) and let the concurrency branch
make the "bar" field into a different type than Lisp_Object.
So you should hate DEFUN which receives function pointer, Lisp_Subr name
and even a comment as parameters :-). I dislike it too, but consider them
as the smallest possible evil rather than a nightmare.
Dmitry
- Re: The rest of xVARs,
Dmitry Antipov <=