IDE Extensions problem

Blair,
    Ever since D5 came out I've been seeing a very intermittent problem with
browsers taking time to disappear after being closed.  A walkback would
occasionally appear if a browser was closed and then, within 30 seconds to a
minute, something was done in another browser to generate one of the global
(#onMethodChanged etc) events.  The browser that was closed would still
respond to the triggered event but cause a walkback as it's view had already
been destroyed.  This didn't happen in a clean image and proved quite
difficult to pin down and reproduce in a workable way.

I always suspected, and am now reasonably sure, that it's down to the
addition of ClosedCommandDescription and the IDEExtension procedure. What
appears to be happening is that...

The closed Browser keeps a reference to the MenuBar.
The MenuBar keeps a reference to the Menu.
The Menu keeps a reference to a ClosedCommandDescription.
The ClosedCommandDescription keeps a reference back to the closed Browser

... and it sits like that for up to a minute, until one part of the loop
(and I suspect it's the Menu) gets destroyed through another route.  I'm a
bit hazy on this bit as it's quite difficult to track it down - the minute
you start actively looking then the problem disappears.

I solved it by responding to the browser's #viewClosed event and explicitly
sending #free to the MenuBar.  This seems to break the loop very early and
causes the closed browser to disappear from the image in the same way as it
would normally.

Does this all sound plausible or am I missing something obvious?

Regards
    Ian

Ian

You wrote in message news:BIdn9.2427$Fv2.236066@wards...
> Blair,
>     Ever since D5 came out I've been seeing a very intermittent problem
with
> browsers taking time to disappear after being closed.  A walkback would
> occasionally appear if a browser was closed and then, within 30 seconds to
a
> minute, something was done in another browser to generate one of the
global
> (#onMethodChanged etc) events.  The browser that was closed would still
> respond to the triggered event but cause a walkback as it's view had
already explicitly
> sending #free to the MenuBar.  This seems to break the loop very early and
> causes the closed browser to disappear from the image in the same way as
it
> would normally.
>
> Does this all sound plausible or am I missing something obvious?


It sounds a plausible reason as to why the browser would not be immediately
GC'd. Where chains of finalizable objects are involved, it can take a few
GC/finalization cycles to occur before everything is destroyed, since only
one item in the chain can be finalized at a time in order that its internal
state is valid at the time of finalization. However I haven't experienced
this issue myself, at least not recently. Some time ago we went through the
system tools to ensure that they explicitly revoked system event
registrations that could cause this sort of thing when their views were
closed (see senders of #removeEventsTriggeredFor:), having realized that in
this case we couldn't rely on weakness/finalization to always clean up in a
timely manner, since circumstances may delay the GC of the browser's
presenters. Its possible that we missed some.

Also Menu's are not explicitly free'd when the owning ShellView is
destroyed, with this relying on finalization; see ShellView>>winFinalize and
ShellView>>releaseMenu, from which it is apparent that the reference to the
menu bar object is nil'd out, but no attempt is made to send #free to it. I
suspect this may be because in the early days we had thought it might be
possible to share menu's between view instances, which is wrong of course,
since the Menu's may display instance specific information.

We can certainly modify this in the next release.

Regards

Blair

Blair,

Thanks for the reply.

> It sounds a plausible reason as to why the browser would not be
> immediately GC'd.

Since I added the fix I haven't seen any occurrences of the problem so it
looks like the tests I came up with were a reasonable simulation of the real
life situation.

>                        Some time ago we went through the
> system tools to ensure that they explicitly revoked system event
> registrations that could cause this sort of thing when their views were
> closed (see senders of #removeEventsTriggeredFor:),

Funnily enough that was the first thing I tried, but it caused a different
problem.  One of the situations were the fault would often (but by no means
reliably) crop up was when I deployed an application with a browser still
open.  When I modified the browsers #viewClosed event chain to include
#removeEventsTriggeredFor: the deployment then always failed with a "Change
flagging disabled" error.  I never chased it up though.

> Also Menu's are not explicitly free'd when the owning ShellView is
> destroyed, with this relying on finalization;
[]
> We can certainly modify this in the next release.

It's probably worth considering.  My modified method seems to work, and I'm
now aware of the situation, so it's not that much of a bother for me but
others who may want to add tools using the IDE Extensions may hit the same
problem.  Your call.

Thanks again

Regards
    Ian