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. Destroying the last interpreter can be very time consuming, when millions of objects are allocated. I don't think this should be the default. Note: only the last interpreter is effected - all other interpreters allways clean up behind them. > Dan leo
