On 7/28/06, Jorrit Tyberghein <[EMAIL PROTECTED]> wrote:
> On 7/28/06, Michael D. Adams <[EMAIL PROTECTED]> wrote:
> > While doing some conversions to the new SCF, I realized a potential
> > issue with the handling of the iEventHandler interface. I may have
> > been inadvertently been adding memory leaks when converting classes to
> > the new SCF. I'm not very familiar with the new event system so I'm
> > not sure if this is a problem or not.
> >
> > Here is the setup:
> > * The class "csFoo" implements needs to register as an event listener.
> > * The "csFoo::Initialize" method registers the event listener.
> > * The "~csFoo::csFoo" destructor unregisters the event listener.
> > * The "~csFoo::csFoo" destructor will only get called when the
> > reference count goes to zero.
> >
> > Does registering the event listener cause a (non-weak) reference to
> > the event handler to be held by the event queue?
>
> Yes it does.
> >
> > If so, then the natural way of writing the above with the new SCF
> > (i.e. "class csFoo : scfImplementation1<csFoo, iEventHandler>") will
> > make any object written in this fashion live at least as long as the
> > event queue (since it never gets unregistered unless it is destroyed
> > which never happens unless it is unregistered).
> >
> > Is this a problem?
>
> Yes it is. The usual solution to this problem is to make the event handler a
> separate object (i.e. not embedded). As far as I know all event handler
> implementations written with old SCF used that system. It appeared like
> it was an embedded interface but actually it wasn't. It was just an
> embedded structure but not linked to the parent.
Yes. Though they looked enough like embedded objects that I mistook
them for embedded objects. Either we need to put a big fat comment at
the beginning of each one that says "This is not an embedded object"
or write them some other way that makes them look less like an
embedded object. (The latter might be difficult b/c the only major
difference between these and embedded objects is whether the parent
holds a weak ref vs a hard ref.)
> > If it is a problem, is embedding the event handler inside the outer
> > class the best solution? (Part of the point of the new SCF is to get
> > rid of those.) Would it be better to have an option during
> > subscription that allowed a choice between using a hard ref (for "fire
> > and forget" event listeners) and a weak ref for cases where the object
> > should just go away and unregister itself if nothing else refers to
> > it? (Is the latter case needed?)
>
> Embedding is IMHO the best solution. Note that we can't really talk about
> SCF embedding here as in this case the embedding is just having an
> inner class which is otherwise unrelated (SCF-wise) to the parent. I
> don't think the weak ref solution is very nice. It would complicate things
> too much.
Hmm, I would have seen pseudo-embedding as adding more complication.
With pseudo-embedding for every object that wants to listen for
events, a new class/object is created who's sole purpose is to act as
an indirection so we can use a weak ref and work around what would
otherwise be a memory leak. The weak ref solution presents a simple
external interface as an option at subscription time (i.e. "do you
want the fact that this object is subscribed to events to keep the
object alive?"). Inside the event handling code this might add
complexity b/c now it must handle two different kinds of references.
I just thought of another solution as I'm typing this. We could make
a generic class ("csWeakEventHandler"?) to act as an indirector and
write a helper function ("RegisterWeakListener"?) that does the usual
subscription but indirected through "csWeakEventHandler". The use of
the "csWeakEventHandler" would be invisible to the user. This way
classes wouldn't be pseudo-embedding (both redundant work and looking
confusingly like true embedding), but it wouldn't have to change the
internals of the event system. I can provide code excepts if this
description isn't clear enough.
Michael D. Adams
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Crystal-main mailing list
Crystal-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
