> #$bar = \$foo; > new P1, PerlRef > stash_load P0, "foo" #Not needed if P0 unchanged > set P1, P0 #Make P1 reference P0 (not 'foo') > stash_store P1, "bar"
My original example was like that, but I wasn't sure if that was a proper use of 'set', since 'set' normally copies one into the other. Of course, we don't have a 'set PMC PMC' yet, so I guess the behavior is undefined. :) > This code seems to be related to differences between documentation and > implementation. Doh, my bad! I've long since learned not to trust documentation, and always use code as the authoritative source. :| > Note that string_repeat and string_substr are documented in the same place > as only creating a new string if the final parameter is NULL; the > implementations again differ. Has anyone decided whether strings are going to be mutable, immutable, or COW? They are currently immutable for the most part, with the exception of chopn, and maybe a few other functions. If we do support COW, then we're probably going to need two versions of every immutable string function, one to return a COW, and one to return a copy. This would allow us to explicitly copy a substring of a large string when we want to avoid having to COW-the large string, if we know we're going to be making modifications to the COW-ed string in a little bit. Implementing COW is a bit harder, although now that we have a DOD pass, a lot easier. We can update counts in there...it's just not very easy to see how we're going to keep track of refcounts. > I agree that the whole issue of garbage collection relating to newborns and > temporaries is problematic. One option might be to always flag newly-created > objects in some way, then have a single function call to release them; at > least this means just one function call at the end of each procedure. This > still leaves a problem with nested procedures. Yeah, all buffer_headers are returned with BUFFER_live_FLAG so that any allocations won't cause them to be lost in the do_collect. But there's no problem with accidentally leaving live on, as opposed to leaving an immortal/immune flag on. There's always macro tricks and/or post-processing of code files, but the latter one is the only one that can handle this case properly, and I'm not sure we want to go there. Perhaps we should delegate to Dan on how to solve the GC-safifying ugliness problem? (distinct from the problem that spawned this thread :) Mike Lambert
