[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] [] can cause instability: tests in primitives?

On 11/21/07, Stefan Kersten <sk@xxxxxxxxxx> wrote:
> On 21.11.2007, at 16:51, Dan Stowell wrote:
> > wrapAt's primitive uses basicWrapAt(), and plot uses unlace which uses
> > prArrayUnlace(), both in PyrArrayPrimitives.cpp. Looks like they both
> > fail to account for an empty array.
> >
> > Could there be some generic way to catch these problems? e.g. this
> > line could (I guess) return nil if empty:
> >
> >  if(obj->size==0) {SetNil(a); return errNone; }
> yes, basicWrapAt is missing the check for obj->size == 0, also for
> the array-as-index case.
> > but would need slightly different versions adding to each primitive.
> > Any better way?
> the solution wouldn't be quite correct for unlace:
> [].unlace(3)
> [[],[],[]]
> i guess (jmc will correct me if i'm wrong), that the newly created
> subarrays (and the result array) need to be reconsidered by the
> garbage collector:
>         SetObject(slots2 + i, obj3);
>         g->gc->GCWriteNew(obj2, obj3);
> , likewise for the sublist elements:
>         PyrSlot* tmp = slots + (i*clump + k + j*numLists);
>         slots3[j+k].ucopy = tmp->ucopy;
>         g->gc->GCWrite(obj3, tmp->uo);
> [ cannot test properly now, still at work :P ]
> <sk>

Objects are allocated white (meaning that it is unknown whether they
are live or dead). GCWrite is meant to protect against a black to
white pointer which is a violation of the incremental collection
invariant: a known live object which has been scanned (black) may only
point to other black objects or objects which are pending being
scanned (gray).

You are free to set slots in a newly allocated white object without
calling GCWrite because the newly allocated object cannot be black. If
you allocate a second object and the collect argument is true then the
above no longer holds since the collection during allocation may mark
your previously white object to gray or black.

--- james mccartney