On Monday 12 November 2007 13:23:17 Bob Rogers wrote: > From: chromatic <[EMAIL PROTECTED]>
> I think it's a freeze/thaw problem actually (as OrderedHash passes > its tests with the gcdebug core, but that is only meaningful if the > test coverage is good). > > It might also have to do with the particular OrderedHash used for HLL > IDs, which would have to be caught at another level of testing. (Not > that I have a theory to support this, though.) I remember coming across something that seemed similar when looking into *ManagedStruct problems with SDL and NCI. My instincts tell me that freeze/thaw are the culprits specifically in OrderedHash. If someone reading this (not just Bob or me) cares to write up some basic tests and can make a failure case, I'm very happy to debug and fix the problem. I'm out of town for a couple of days and may not get to the tests for a while, but I will fix the problem unless someone beats me to it. > Is it a huge, invasive change to make Kea-CL *not* load PBC files, > instead loading PIR files? If you can do that for all files with subs in > namespaces, I'm curious to see if the problem goes away. > > I can (it's easy), and the problem does go away. The way HLL directives work with PBC is that each Parrot interpreter keeps a PMC around to map HLL information and types. PBC stores a frozen interpreter to store this information. When Parrot loads a PBC file, it thaws that interpreter and merges the HLL information back into the invoking interpreter. If there's a problem with that freezing or thawing, we'll lose some information about HLLs that was present when it comes from PIR. That's why avoiding the PBC step works around the problem. I don't think it's a merge problem because I saw something similar when using OrderedHash within *ManagedStruct PMCs, but it's possible that I'm wrong. I didn't see any good freeze/thaw tests for any of our PMCs, and the code in OrderedHash looked a little weird, so that's why I think there's at least one bug lurking there. -- c
