[ENH] EventEnhancement-nk

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Thu Jun 19 15:01:57 UTC 2003


On Wed, Jun 18, 2003 at 11:21:38PM -0700, Andres Valloud wrote:
> Hi.
> 
> > I'm confused.  Don't strong references lead to "memory leaks" when
> > you forget to remove the event registration, and objects that you
> > thought would be GCed are not?
> 
> Exactly.  Instant debugging material, which results in better
> understanding and a better implementation or design.  See John's email,
> it's a great explanation already.

I understand that strong references force you to have a better
understanding of your design if you want to avoid memory leaks.
Looking back at your previous response, you said "strong references
made it easy to enforce zero memory leaks".

I read "enforce" as "avoid", hence my confusion.  My fault.

> 
> <><><><><><><><><
> My vote is for regular MessageSend objects. (That's why I used them. 
> :-}>) Having used this mechanism extensively since Steve Messick 
> introduced it in Smalltalk/V Mac 2.0, I have found that the time spent 
> figuring out where dependencies should be released invariably led to 
> improvements in my design and a better understanding of the temporal 
> dependencies of the subsystems. I have found this to be the case with 
> the original changed/update mechanism as well.
> 
> In my experience, loose coupling defines a de facto session of 
> observation. Making the (de)registration explicit forces the designer 
> to be aware of a session of observation and when that session begins 
> and ends. This becomes particularly important in distributed systems in 
> which observation may be occurring over remote links. I know from 
> experience that explicit registration and deregistration as the 
> demarcation of session boundaries is extraordinarily useful in these 
> contexts.
> 
> Most of the arguments I have heard for weak registrations fall in the 
> camp of "I don't want to think about the consequences of 
> dependency...". In over a decade of use, I have never had the need for 
> weak dependents.
> <><><><><><><><><
> 
> > "If the intention to allocate memory via object instantiation is
> > explicit, so must be the intention of deallocating it at the
> > appropriate time."
> 
> It depends - who is saying this?  

Me (with my Devil's Advocate hat on)

> This is fine as far as the VM is
> concerned, but it seems to me that we're past the point where we think
> in terms of allocating memory when we send new.  

That's my point.  Now we take it for granted.  Perhaps some day we
will take for granted that an object needn't explicitly de-register
itself with event producers before it is GCed.

I haven't done much distributed programming, and none in Smalltalk; I
was approaching the question in the context of single-image
programming.  From that perspective, a solution like Andreas proposes
seems preferable to either the pure strong or weak reference approach.
Without programming more distributed systems, I can't really comment
on whether this would still work.  Obviously, a remote event producer
can't just check whether an object has been GCed to notice that it
doesn't have to notify that object of an event.

Joshua

> That's the beauty of pushing memory management to the VM, it just
> can't stand in your way.
>
> Andres.



More information about the Squeak-dev mailing list