I've just convinced myself that Tcl's problem is an interaction with the .HLL directive and PBC. That is to say, the assumption that you can freeze PMC Subs and thaw them in a different process is broken.
Why? Subs may have an association with a HLL. Right now, that's an integer--the unique identifier of that HLL: PMC_sub(sub)->HLL_id. Where does that integer come from? It's in src/hll.c, specifically Parrot_register_HLL(). The integer is an offset into an array of HLL information. (At this point, you should be thinking "Hmm, arrays are first-come first-served! What if you load several PBCs which each have HLL information and which were all created independent of each other? Those unique identifiers are only unique within that process!" You'd be right, too.) Upshot: if I modify src/tclsh.pir by changing all occurrences of 'pbc' to 'pir' and run Tcl tests via parrot src/tclsh.pir instead of parrot tcl.pbc, I don't get the mysterious errors. This means: we ought to be using the unique HLL names as HLL identifiers throughout the system, because they're less likely to overlap. (I did think of doing fixups when loading bytecode... but ow, yuck.) This means: a rewrite of src/hll.c is in the works. Fortunately, there's a workaround for Tcl. -- c
