ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] cleaning up services
Date Wed, 05 Jun 2002 06:50:33 GMT
On Tue, 4 Jun 2002 18:06, Peter Donald wrote:
> Hi,
> On Tue, 4 Jun 2002 11:57, Adam Murdoch wrote:
> > Hi,
> >
> > There's a few places where we're not cleaning up services:
> >
> > - Scoped services in partitioned execution frames.
> > - Services created by a workspace.
> > - Task listeners.
> >
> > Any thoughts on the best way of dealing with these?  We have a couple of
> > options: use Disposable, or add a cleanup method.
> >
> > For execution frame and workspace, a cleanup method might be better. 
> > Main reason is that it is their clients, rather than the container, that
> > need to inform them that they're no longer needed.
> How about "void close()" instead as that seems to fit in more with what you
> are doing (ie deallocating resource rather than "cleaning" it to prepare
> for reuse).

Yep, that's what I meant.

> > For listeners, being on the other side of the task api, we really
> > shouldn't use Disposable.  Which leaves a cleanup method, which the event
> > manager would be responsible for calling when it gets disposed.
> Why do you think that the EventManager should call close? My initial
> instinct would be to make it a responsibility of the caller. I could quite
> easily see the same listener reused after embeddor is shutdown and
> restarted. Thoughts?

I did consider this.  The problem is with tasks that add a listener that has 
to live beyond the lifetime of the task that creates them, eg <sound> (or 
some generic <add-listener> task, say).

What I was thinking of doing was to add some method that the event manager 
calls to notify the listener that it won't be getting any more events.  It 
doesn't necessarily have to be a close() method.  It could be a 
taskFinished() event, with a path of (say) "/", or something like that.

Making the creator responsible for cleaning up is a good option, though.  
Listeners that need to live beyond the task that creates them could do some 
trickery with the task paths to figure out when they are no longer needed.  
Or install some service that cleaned them up, or whatever.  ie we simply add 
TaskListener.close(), and anything beyond that is not our problem.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message