On Thu, 9 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Thu, 9 Oct 2003, Juergen Boemmels wrote:
>
> >> Hi,
> >>
> >> I just discovered a really subtele bug:
> >> Normaly the test are not run with --destroy-at-end. This has not many
> >> consequences yet because the only PMCs with active destruction are
> >> IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it
> >> won't flush its buffers without --destroy-at-end. The print op also
> >> did not use this buffer so this bug didn't even show up.
> >>
> >> There are several ways to solve this:
> >> - run the test always with --destroy-at-end
> >> - make --destroy-at-end the default and have an option --no-destroy-at-end
> >> - add a explicit flush to the test just before the end.
> >>
> >> I think we should take the second route: destroy-function should be
> >> run by default at the end of program.
>
> > Option 2 is the right one. (Well, OK, having parrot do an explicit sweep &
> > destroy's the right option, but until then...) Go ahead and add a patch to
> > whatever you need to make this happen.
>
> 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
> 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.
> 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.
Dan
