At 08:33 AM 8/6/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
> > >Why waste space on flags? The vtbl should handle that.
> >
> > Because some flags are universal, and if they're not, this field
> > gets tossed.
>
>Flags that vary only when the vptr varies could go in a field of the
>vtable for speedy access. I'd like to see us try to avoid a flags
>element in the Perl 6 SV.
I'm not that worried about it at the moment, certainly not for space
reasons. Trying to avoid a flag field's OK, but I'm not sure how far its
worth going.
> > >Put the sync data into a seperate area and then access the external data.
> >
> > There lies race conditions. (cf 5.6.0's lock issues) For synchronization
> > data to be valid it must be there at creation time. If it needs to be
> > tacked on later you run into race issues with multiple threads trying to
> > init the sync data.
>
>If the stuff lives in an arena, have one mutex-init lock per page of
>the arena.
Gah! No! Bad! That can lead you to odd deadlock situations that are
damnably hard to debug. Locking an arena page means different threads
working on unrelated data can run into each other. It's sort of the moral
equivalent of unconditionally locking all the variables used in a sub every
time you enter that sub.
Threads and locking is tricky enough that I'd like us to be really
conservative about it until we actually need to get more daring, so I'd
prefer to be as correct as possible.
>This avoids requiring non-shared values to contain individual mutexen.
I expect anything could be shared at any point. Perl's flexible enough
about other things, it ought to be flexible about this, too.
> > >And why carry around IV/NV and ptr? Make it into a union, to allow
> > >room.
> >
> > Speed? Valid tradeoff, though. We can do it both ways to see what's
> > better.
> >
> > >The string/number duality should be handled by the vtbl. So a
> > >string that is never accessed as a number, doesn't waste the
> > >space. And numbers that are rarely accessed as a string save some
> > >room. And as needed the vtbl can be promoted to a duality version
> > >that maintains both.
> >
> > I agree with this, though I'm pretty sure most scalars end up with
> > multiple types. I'm up for either way, though--
>
>Really? I find Perl 5's IV/NV/PV/PVIV/PVNV contraption with the fake
>structure offsets kind of charming.
I find the fake struct thing worrisome for debugging reasons--you can't run
a normal perl through purify, for example, because of this. But the vtable
code can manage on-the-fly morphing, so I'm not worried.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
