https://codereview.appspot.com/5847053/diff/5001/source/drafts/stopping-units.rst#newcode94
source/drafts/stopping-units.rst:94: and garbage collects their topology
footprint and zk state.
On 2012/03/21 20:07:53, niemeyer wrote:
> What about garbage collecting on the next action after the decision
that it's
> fine to GC it? I don't think we need a specific process that has the
task of
> GCing the topology.
> In both cases, though, we have an issue: when is it ok to GC it? This
proposal
> is not providing any means for deciding on that, which means the data
becomes
> eternal. That hole indicates postponing that side of the problem may
not be a
> good idea. We can do something simple, but it'd be good implement
cleaning up at
> the same time.
wrt to when is it OK to GC it, i've added an additional section to the
document regarding when its okay.
Please take a look.
https:/ /codereview. appspot. com/5847053/ diff/5001/ source/ drafts/ stopping- units.rst drafts/ stopping- units.rst (right):
File source/
https:/ /codereview. appspot. com/5847053/ diff/5001/ source/ drafts/ stopping- units.rst# newcode94 drafts/ stopping- units.rst: 94: and garbage collects their topology
source/
footprint and zk state.
On 2012/03/21 20:07:53, niemeyer wrote:
> What about garbage collecting on the next action after the decision
that it's
> fine to GC it? I don't think we need a specific process that has the
task of
> GCing the topology.
> In both cases, though, we have an issue: when is it ok to GC it? This
proposal
> is not providing any means for deciding on that, which means the data
becomes
> eternal. That hole indicates postponing that side of the problem may
not be a
> good idea. We can do something simple, but it'd be good implement
cleaning up at
> the same time.
wrt to when is it OK to GC it, i've added an additional section to the
document regarding when its okay.
https:/ /codereview. appspot. com/5847053/