fixed address objects (was Calling straight C code)

Stephen Pair spair at advantive.com
Wed Mar 10 00:19:12 UTC 1999


I agree, and for that reason, I would not use ExternalByteArray in the POSIX
R.E. example you give.  I would instead wrapper such an entity with it's own
class that makes calls to the interface to allocate and de-allocate these
structures.  There are however a number of cases where ExternalByteArray is
useful and justified.  And, with proper wrappering of such complex
structures, any references found the the bits, would also be reflected in
instance variables.  Also, whether you use fixed objects or an
ExternalByteArray, there is no difference in the issues that could arise if
an external entity obtains references to them (in either case GC could
reclaim the memory).  Therefore, great care must be taken...but in my
opinion that doesn't negate the usefulness of such constructs in wrappering
non-smalltalk libraries and communicating with the external world.

Without such construct you are left with two options when interfacing to the
external world:

1.  Rewrite it in Smalltalk
2.  Write primitives to interface to the external world

Each of these options has it's own problems.  It goes without saying that
number 1 is not always an option, however it is usually the preferable path.
Number 2 will result in the VM growing ever larger, is rather in-flexible
when the external code changes to add new features, and forces a lot of
things to be handled in C that could be better handled in Smalltalk (like
abstracting platform dependent code).

You do open the door for someone to write bad code and crash the system, but
why does that really matter?  Once you wrapper a piece of external code and
have rid it of such issues, you really don't have to worry anymore about
issues of crashing...and isn't that one of the things that makes OO so
powerful?

But that's just my opinion, I could be wrong.

- Stephen

> -----Original Message-----
> From: agree at carltonfields.com [mailto:agree at carltonfields.com]
> Sent: Tuesday, March 09, 1999 5:18 PM
> To: rowledge at interval.com; squeak at cs.uiuc.edu
> Subject: RE: fixed address objects (was Calling straight C code)
>
>
> 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 >>
>





More information about the Squeak-dev mailing list