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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]