Re: Removing probeDisplays...

[Roger M. Burkhart]

Barry McMullin writes:

> The 1.0 release notes include the following:
> 
> 9. Any object now supports an ability to register an external reference to
>     the object, and to have this reference notified (via the calling of a
>     function) whenever the referenced object is dropped.  Registration of
>     references will allow automatic dropping of probes when the objects they
>     refer to disappear; currently such probes still crash.
> 
> I'm sure this is all fine and dandy; but for the
> specific problem of not dropping probeDisplays, it
> seems to me that it should be as easy (maybe easier) to
> use:
> 
>   [probeDisplayManager removeProbeDisplayFor: self];

But the problem occurs when an object is dropped unbeknownst to the display
object that's probing it.  Objects can be dropped all the time by the
normal running of a model, but right now a probe display goes on trying to
keep probing it regardless.  Because an object can make no assumptions
about the environment it's running in, batch or GUI, probed or not, it
doesn't ordinarily have any form of access to the probeDisplayManager to
remove itself from, assuming there even is one.

> Better yet, how about incorporating this into the
> default -drop method on SwarmObject - then we would
> never have to worry about hanging probeDisplays causing
> a crash ever again?
> 
> Or am I missing something?

Yes.  The first problem is the one I already mentioned about a SwarmObject
knowing what probes (could be more than one) are probing it.  The second
is that we don't want to build in the overhead of a whole lot of
special-purpose probe logic into something so basic as the lifecycle of
every object in any simulation.  Generic probe support is currently
provided on every object at *zero* cost to the normal execution of the
objects and model, and this remains true with the new notification
apparatus.

The new notification apparatus adds a tiny, one-bit-check bit of overhead
to the standard drop message that will notify an external, dependent
reference such as a probe of an object's disappearance, but the cost of
actual notification is incurred only if such a reference actually exists.
In the case of probes, the number of objects on which probes typically
exist is a very small proportion of all objects, so we don't want to pay a
cost for this special case for every case.

You have suggested the right solution, which is to build probe removal
into the standard drop message, but missed the point that the drop
notification machinery is the very mechanism to do this in a carefully
tuned way.  Carefully tuning the decisions about when and where any
performance cost should occur has always been a major design issue for
Swarm.

The real answer is that Swarm still needs to incorporate drop notification
as part of standard probe displays; the only reason the crash remains is
that this hasn't been done yet.  This should go on a short list of things
to get into upcoming Swarm releases.

-Roger