You may wish to consider the propriety of using a Squeak object to represent External memory for memory sought by external code.  In cases where the external memory does not itself contain cross-references to other external memory, you can sometimes handle things through a handle to a real ByteArray instantiated in the ordinary course of events (or copied from the malloc buffer before returning to the Squeak world).  In cases where there ARE cross-references (the reason why you care that the memory must be fixed address objects), it may not be appropriate to murder the object simply because the Squeak world lost its references to it.  Squeak WILL NOT KNOW whether another fixed memory block is pointing to the byte-array.  Accordingly, finalization may be very application-specific, and it may not be desirable to finalize the fixed memory just because Squeak dropped its reference.

Consider the POSIX regular expression interface.  Upon generating a regular expression object, you get a handle to a fixed size block, which in turn contains pointers to a plurality of variable sized blocks.  The variable sized blocks are recovered only when the fixed block is recovered, through a POSIX call for that purpose.  Squeak has no need or interest to hold handles to the variable sized objects, although they may well be allocated via ExternalByteArray.  The actual physical space buffers should NOT be recovered, therefore, through finalization of the handles to the ExternalByteArray objects, but rather through the internal system call.

I suspect situations like this will be common precisely in those circumstances where the external memory must reside in fixed address objects.  (as noted, the cross-references are probably the reason they needed to be fixed in the first place.)

-----Original Message-----
From:	MIME :rowledge at interval.com Sent:	Tuesday, March 09, 1999 4:45 PM
To:	squeak at cs.uiuc.edu
Subject:	RE: fixed address objects (was Calling straight C code)

On Tue 09 Mar, Raab, Andreas wrote:
> Tim,
> > > A _much_ better solution would be to find some way to convince Windows to
> > return memory chunks with higher addresses.
> I can do this - all I'd have to do is to dig up the GNU (or some other)
> malloc implementation that allows me to supply a custom sbrk().
That would be great, if it can be done without too much trouble. It would
provide for having objects of any class that are non-moving, allocatable from
either Squeak or C code and lockable (in case the Ccode wants to keep them even
when Sq has no further references).
 > PS. I'm still not convinced that Windows is the only platform where this
> might be a problem ;-)
You may well be right, but I haven't run across another case yet. IIRC this was
a problem for PPS in a similar way, back when we were doing ObjectWorks 4.0 -
and again only Windows (3.0 in that case!) was a problem.


AND;
On Tue 09 Mar, Stephen Pair wrote:
> > Another
> > route to getting much of the functionality that
> > this provides might be
> > a decent memory proxy setup, perhaps using the weak pointers
> > stuff to free it.
> > Anybody done that?
> > I created an ExternalByteArray class that does it.  Maybe I could find
> sometime to dig it up and clean it up this weekend if anyone is interested.
> It shares ByteArray's protocol and uses finalization to free the external
> memory.
>
This would solve my immediate problem (actually, the stuff I have does, but
until and unless Andreas can deal with the above, it's not portable and that is
not acceptable to my mind) and might solve a simialr problem Andreas was
talking about recently. The main problem with any sort of proxy is that prims
like BitBlt would need some ugly mods to allow their use as Bitmaps or
whatever. However, for OS resource handle type doodahs they're great.


tim

-- Useful random insult:- A .22 caliber intellect in a .357 Magnum world.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>


 << File: ENVELOPE.TXT >>