Dan Sugalski <[EMAIL PROTECTED]> writes:

> > I disagree :) We already have a 2 stage IO destroy. The first shall
> > flush its files. This get called even if destroy-at-end isn't set.

The two stage IO destroy is a problem that we don't have destruction
ordering yet. Closing the standard handles to early leads to failed tests.

> > The
> > second phase (clean allocated memory) isn't called for the last
> > interpreter, if this option isn't given. So either this test has to set
> > the "needs_destroy" on the IO object or IO has a bug.

No, needs_destroy marks the object that it needs _early_ destruction,
not that it needs destruction at all. The problem that the
destruction code is not run run at all.

> > If there are objects that did "needs_destroy" then a lazy sweep is done,
> > which should flush the IO object or release resources or whateve rsuch
> > an object might need.
> 
> No. If any object has a destructor it should be called as the last
> interpreter is shut down. We're not guaranteeing dead-on immediate
> destruction, or if the timely flag isn't set timely destruction, but we
> *are* guaranteeing eventual destruction.
> 
> We don't need to free memory, but we do need to call destructors.

Exactly. My first idea --destroy-at-end only removed the symptom. The
real problem was that the final sweep, which should have run the
destructor code, was only triggered if there was still an object left
which needs early destruction. I changed this to run the final sweep
unconditionally and the problem disappeared. I did not touch any of
the --destroy-at-end semantics.

I thought one moment about introducing a variable
interpreter->has_destroy analog to interpreter->has_early_DOD_PMCs but
rejected it. This would slow down the DOD because it has to take care
of this variable also. I think its better to force one sweep at the
end than slowing down every DOD.

bye
boe
-- 
Juergen Boemmels                        [EMAIL PROTECTED]
Fachbereich Physik                      Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern             Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Reply via email to