On Wed, Aug 14, 2002 at 03:16:20AM -0400, Mike Lambert wrote: > > If the rx info object is going away, then obviously those parts of the > > patch need not be applied. But in the meantime, it's nice to have a > > Parrot that doesn't crash. > > I agree. My disclaimer about the regex code in my original email was to > suggest that we didn't need to focus on the rx issues, but if you've > already done it... :)
Yes, I knew that when I tackled it, but after climbing the painful learning curve to fix all the other problems, I figured I might as well nail this one down too while I was in there and in the right mindset (or maybe it was just that I didn't want to delete my zillions of debugging printouts quite yet...) > > In summary, this patch > > > > - Adds an OUT parameter to new_hash() so the hash is anchored to the root set > > while it is being constructed. > > - Adds an OUT parameter to hash_clone() for early anchoring. > > - Adds an OUT parameter to rx_allocate_info() for early anchoring. > > - Briefly disables DOD while a stack is being created so allocating the contents > > of the stack buffer doesn't destroy the unanchored buffer header. > > These are needed for now. However, when we get that buffer/pmc unification, > we should be able to make mark() methods in the header pools. Then, with > support for non-pmc-wrapped buffers, we can find references to them > on the system stack, and call their mark() method directly, avoiding > the above hoops. At least, that's my hope. Is it possible to mark the > above code with some XXX tag so that we can re-address it when we get the > unification in place? That will fix some of these problems, but not all. For one, the Pointer PMC needs a custom mark routine in order to work properly *after* the initial creation, because whatever the Pointer PMC points to may contain PMCs and Buffers that probably won't be on the system stack after creation. So some way to define a custom mark routine will still be needed (or we'll need to restrict Pointer PMCs to point to objects that are not subject to garbage collection, either because they are allocated externally to Parrot, or they are anchored in some other way.) Also, the rxinfo struct and the Stack_Chunk_t struct are both allocated with mem_sys_allocate, so they won't be helped by making Buffers smarter. The problem is that the system stack walk only sees the address of the struct, and doesn't know how to delve inside it. I don't know if there's any good reason why they can't be allocated with new_bufferlike_header (that's how the hash struct works), in which case the smarter Buffers would fix the problem. Or was this what you were intending? If so, then I'll plaster each of those with a FIXME comment. Otherwise, I'll leave them as-is.
