https://bugs.documentfoundation.org/show_bug.cgi?id=158913
Armin Le Grand <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] |desktop.org | Status|NEW |ASSIGNED --- Comment #3 from Armin Le Grand <[email protected]> --- Happens as described. Also quickly found the problem - the Primitive is deleted while being in use. The original concept designing the Primitives was to have read-only, small, unchangeable objects. This is undermined by the 'visitor' concept - the instance owning the Primitive decomposition/representation 'directly' uses that representation, while at the same time that instance is allowed to re-create (and thus also delete) that instance. This can/could not happen without the visitor concept before: The instances were fetched and held safe ref-counted (that's why Primitives can be held by uno::Reference). I see the (small) advantage here by using that visitor concept, but: - less ref-counting (guessed initial reason for visitor concept?) is easily possible by packing decompositions in single references by themselves (Group/transformPrimitive with neutral transformation), so no need to achieve that advantage by 'visitor' concept and pay the security price for it - potentially more usage of multi-threading with Primitives, esp. for expensive decomposition ceations combined with timing stuff So - for the future - I would really prefer safety/ref-counting over small advantages (other achievable, see above) here. For now I will probably just make that safe using a std::mutex to ensure that the local decomposition gets *not* changed while being 'visited' - with the known possible costs for multi-threading. Of course only when really needed, to minimize possible impact(s)... -- You are receiving this mail because: You are the assignee for the bug.
