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.''
> >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. 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?
> 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.
Agreed.
> >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.
Hmm, yes.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
