Problem with pointer fields in structures

I have a subclass of ExternalStructure (let's call it StructA) that includes
a field for holding a pointer to an array of other structures (StructB).
The #defineFields method for StructA looks like this:

StructA>>defineFields

    self
        defineField: #childCount
        type: SDWORDField new.
    self
        defineField: #children
        type: (VariableStructureArrayPointerField type: StructB length:
#childCount)

I can set the child count and the #children field of an instance of StructA
via the following,

    instanceOfStructA
        childCount: 5;
        children: (StructureArray length: 5 elementClass: StructB).

If I then inspect instanceOfStructA, the pointer held in the #children field
appears to be invalid as the StructureArray returned via #children holds
StructB instances containing what appears to be garbage data (rather than
0s).

However, if I assign the instance of StructureArray to a workspace variable
prior to sending #children: to instanceOfStructA, everything works ok.
e.g., The #children accessor of the StructA returns a StructureArray of
StructB's initialized with zeros.

I'm assuming this problem is related to the garbage collection of the
StructureArray that I'm creating as the argument to StructA>>children: and
that the memory associated with the StructureArray is being deallocated as
part of the gc process (thus, the garbage when attempting to inspect that
data returned by #children).

My question (finally) is,
Is there a way to prevent this memory deallocation from happening without
keeping around an explicit reference to the StructureArray?  (Note: I've
tried setting the instance of StuctA as the "owner" of the StructureArray
but still have the same problem).

Regards,

Chris Hayes

Chris,

I remember the EducationCentre says something like to prevent gc from
removing the reference, you should create an instance variable in the
ExternalStructure (and assign it as long as it's needed).  That sounds to be
consistent with what you're experiencing.

> Is there a way to prevent this memory deallocation from happening without
> keeping around an explicit reference to the StructureArray?

"Louis Sumberg" <[hidden email]> wrote in message
news:a3flc5$fnf$[hidden email]...
> Chris,
>
> I remember the EducationCentre says something like to prevent gc from
> removing the reference, you should create an instance variable in the
> ExternalStructure (and assign it as long as it's needed).  That sounds to
be
> consistent with what you're experiencing.
>


Thanks, Louis.  Sounds good.  I agree, that should do the trick (although I
wasn't able to find the spot in the Education Centre you're referring to).

The other thing I was wondering is if there's a class in Dolphin that allows
memory to be allocated within ST and NOT be deallocated when the allocating
object was finalized.  i.e., Explicit allocation and deallocation.
Something similar to ExternalMemory but with a  #finalization method that
did nothing.  If you had such a thing, the "owning" structure (in my
scenario) could store the address of the structure or array (as usual)
without needing to keep an ivar reference to the allocated memory around.
Then, when the owning structure was freed or finalized, it could explicitly
deallocate the owned, "subordinate" memory.

"Chris Hayes" <hayes@*zapthis*.creative-computing-inc.com> wrote in message
news:Dsd78.3222$[hidden email]...
> "Louis Sumberg" <[hidden email]> wrote in message
> news:a3flc5$fnf$[hidden email]...
> > Chris,
> >
> > I remember the EducationCentre says something like to prevent gc from
> > removing the reference, you should create an instance variable in the
> > ExternalStructure (and assign it as long as it's needed).  That sounds
to
> be
> > consistent with what you're experiencing.
> >
>
>
> Thanks, Louis.  Sounds good.  I agree, that should do the trick (although
I
> wasn't able to find the spot in the Education Centre you're referring to).
>
> The other thing I was wondering is if there's a class in Dolphin that
allows
> memory to be allocated within ST and NOT be deallocated when the
allocating
> object was finalized.  i.e., Explicit allocation and deallocation.
> Something similar to ExternalMemory but with a  #finalization method that
> did nothing.  If you had such a thing, the "owning" structure (in my
> scenario) could store the address of the structure or array (as usual)
> without needing to keep an ivar reference to the allocated memory around.
> Then, when the owning structure was freed or finalized, it could
explicitly
> deallocate the owned, "subordinate" memory.

You can use the ExernalMemory class side method #Alloc: to allocate a block
of memory that is pointed at by a non-finalizable ExternalAddress object.
This will have to be explicitly free'd (ExternalMemory class>>Free:) or it
will leak.

You could certainly do what you say (and in fact for certain externally
allocated structures this style of memory management is already used), but
typically it is easier and more flexible to use an instance variable to
create a reference that is seen by the garbage collector. It is easier
because one doesn't have to worry about making the structure itself
finalizable, and one doesn't have to implement the explicit free either
(which tends to be error prone). It is more flexible because by using an
"object", the object can decide how and if it needs to free the external
memory.

Regards

Blair

> I wasn't able to find the spot in the Education Centre you're referring
to.

Chris,

It's at EducationCentre/Dolphin Developer's Guide/External
Interfacing/External Memory Management.

The reason I "remembered" seeing it is because I've been reading, rereading,
rereading, and rereading the External Interfacing section the past few days.
Ah, if only it would sink in.

-- Louis