Re: deferred deallocation of local objects

[Alexander Malmberg]

Well, I haven't had time to look at this properly yet, but as far as I
understand it, what happens is:

Process(/thread) A is running an object O.
Process B has a proxy for this object (and is connected to A in some
way).
Process C is connected to B.

When something in B tries to send O to C, it doesn't tell C to create a
proxy for an object at B. Instead, it sends information about how to
contact A, and the id number of the object in the DO system of A. C then
uses this information to connect to A and create a proxy.

The (potential) problem here is that B might release O after sending the
information to C, but before C has time to connect to A and retain the
object. In that case, unless something else is retaining O, A will
remove its id number (and potentially deallocate it). By delaying the
release in A, C gets more time to connect.

Note that B might release O indirectly, eg. if B dies and A notices that
the connection is dead.


Anyway, there are several potential solutions, with varying degrees of
beauty and backwards compatibility (I haven't had time to check this
properly).

Some obvious solutions involve B, eg. to have B block and wait for a
confirmation from C that it has connected to A and created the proxy
(and this may be how most calls already behave in practice).

However, I don't like the idea of mixing B into this. B should, IMHO, be
able to send off the messages and forget about it. Having B block on
each such call would not be good for B's performance. Deferring the
release in B doesn't work because there might be code in B that just
calls exit(0) when it thinks that it's done (and doesn't know that it
needs to wait for C). Also, if B crashes, or the connection between A
and B or B and C dies before the confirmation, O might be released early
anyway and C is out of luck.

I think a better solution would be to have B send a (oneway)
potentialRetain (or something) to A before sending the information to C.
C would then send a grabPotentialRetain instead of a normal retain when
creating the proxy.

In A, these retains would maintain a "potential retain count" which
increases by one for each potentialRetain and decreases when
grabPotentialRetain turns it into a normal retain. Ungrabbed potential
retains will keep an object alive, but would timeout after some set
time.

This way, B isn't involved at all after sending its messages (so it can
exit/crash/pull the plug without affecting A and C), we correctly handle
long delays (until the timeout runs out), and the delays in object
deallocation or no longer than they have to be (as soon as C connects,
the potential retain goes away and the object can be released normally).

Comments? Thoughts?

- Alexander Malmberg