Hmm, somehow this slipped through the cracks as I was changing list
subscription addresses. Oh, well.
Below are my quickie, off-the-cuff reactions to Dan's RFC #35v1.
Recipe cum grano salis.
>The base variable structure looks like:
>
> struct {
> IV GC_data;
> void *variable_data;
> IV flags;
> void *vtable;
> void *sync_data;
> }
Cool.
>The fields, in order, are:
>
>=over 4
>
>=item GC_data
>
>Random data for the garbage collector, whichever one is used. This
>could be a marker for M&S GC, or a refcount for refcount GC, or just
>nothing at all if we get a really clever GC.
Really clever, like M&S and using the bottom pointer bit as the
marker. There is no need for an IV as marker. Not to mention, that
if these structs are passed around by value instead of required to
live in some arena, they won't need *ANY* GC data. Clever!
>=item variable_data
>
>Equivalent to perl5's sv_any pointer, this is a pointer to the actual
>data structure for the variable. It may, in certain cases, be coopted
>to hold the actual value.
Go Dan!
> (This is likely the case for a scalar that
>holds just an integer, where the native int size is equal to or
>smaller than the native pointer size)
>
>The actual structure that hangs off will depend both on the class of
>variable (scalar, hash, array) and the type of that class (integer
>array, integer scalar, filehandle, reference) and isn't specified here
>
>=item flags
>
>This field holds various flags that hold the status of the
>variable. (Flags to be RFC'd later)
Please RFC the flags pronto. Maybe we don't need any.
>=item vtable
>
>The vtable field holds a pointer to the vtable for a variable. Each
>variable type has its own vtable, holding pointers to functions for
>the variable. Vtables are shared between variables of the same
>type. (All integer arrays have the same vtable, as do all string
>scalars and so on)
>
>vtable contents will be RFCd separately. All variables will share a
>common set of functions, though scalars, arrays, and hashes will have
>their own set of extensions on top of that.
Okay, vtables are yummy. I'll take a vptr along with my
variable_data, please. With a nice, big, fat vtable on the other end
and lots of sauce.
>=item sync_data
>
>A pointer to a structure used for synchronization between async parts
>of perl. This will probably be used mainly for threading, but may be
>used to indicate interpreter ownership for variables shared between
>interpreters, or other such things. If 0, the scalar is assumed to be
>unshared and no synchronization is done.
Interpreter ownership: Stuff that exists "by value" does not need an
owner. Stuff that lives in an arena should be able to find its
interpreter with something like *(Interpreter**)(ptr & ~0x3ff).
Thread mutexing: only special fat shared_things can be mutexed.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
