At 10:30 AM 8/6/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > 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.
>
>Would you consider adding something like this to the RFC?
>
> ``Abundant macros, inline functions, and API functions will be
> used wherever possible so as to allow fundamental changes to the
> internal representation.''
That belongs in a different RFC, the one roughing out the embedding,
extension, and opcode APIs. (I've got those half-done too... :)
> > >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.
>
>Sorry, I fail to see why. To upgrade or destroy an object:
>
> 1. lock the object
> 2. lock the source arena
> 3. lock the destination arena
> 4. move bits
> 5. unlock the destination arena
> 6. unlock the source arena
> 7. unlock the object
>
>SVs are never downgraded, so no one's source and destination are
>another's respective destination and source.
SVs will get downgraded in perl 6. If you do:
$foo = "12";
$bar = $foo + 1;
$foo = 2;
$foo may get switched over from being a mixed float/string scalar to a
plain integer one.
It's probably more appropriate to say that variables will get morphed from
one type to another, rather than up and down graded. Since switching's
likely cheap enough (or the optimizer can take a good shot at guessing when
its appropriate) it shouldn't be a big deal. I hope.
>Maybe the above sequence
>isn't exactly right, but if we adhere to strict rules for lock
>sequencing, there won't be a deadlock, right?
There's more to it than just that, though. Variables need to be locked when
they're accessed, not just when they're copied from place to place. Writes
may not copy them, just access, and perl's variables are big enough that
there's no guarantee of atomicity anywhere that we don't explicitly write
code for with locks.
I'm starting to lean to a threaded/unthreaded pair of vtables for each
variable type, so you only call the locking code once a variable's been
explicitly shared (and therefore has a valid threading vtable as well as
presumably a valid sync structure)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
