Version 3 (modified by 14 years ago) ( diff ) | ,
---|
Issue RenderObject lifetimes RO destroyed in Node::detach(), which is badly named.
Complications
anonymous containers continuations multicol stuff who else is pointing at you
float lists in lines continuations line boxes around inline replaced elements
Would like a WeakPtr system (but high memory cost)
Why do you use RefPtr
secondary use can hold a ref
Can we use OwnPtr?
just helps you not leak, and documents explicit ownership we don't use OwnPtrs because of RenderArenas are they still a useful opt? Need to measure
RO guard is like a debug-only RefPtr. Maybe that's how it should be implemented.
Two approaches
- Global "I'm holding a ref to some renderer, so don't destroy any". Addresses risk of being too specific
- Smart-pointer type object: RenderPtr.
(We look at some stack traces). We should protect against higher-level re-entrancy issues e.g. updating style/layout in painting.
How would we fix these?
make sure you're actually done before releasing the protector
Need to handle "zombie" renderers: need to avoid having this be a worse issue.
Actionable things Rename the detach() method Measure the cost of removing RenderArena