Krita shared pointers usage

[Boudewijn Rempt]

On Mon, 15 Dec 2014, Stefano Bonicatti wrote:

<...>

> Only by opening and closing one image i got 26k refs and 26k derefs of that single pointer, that seems to me quite a lot for such a
> simple operation.

That sounds quite excessive indeed!

> It's true, this even helped me pinpoint where the shared pointers containing the rootLayer where held beyond the correct time

Where did that happen?

> 
> What i'm proposing:
> 
> Shared pointers should be used as class fields, to acquire just allocated memory or to keep alive objects used by threads.
> 
> The first one should be clear, the second one means that as soon as one has a "new" of something, the pointer should be put inside a
> shared pointer.
> In general though the shared pointers, wherever they are, shouldn't be passed down the stack, but up.
> So for instance if one has some function that allocate memory.. then it is ok for it to return a shared pointer (this is passed up the
> stack).
> If though an object is allocated and then passed down the stack in a code that maybe sets this shared pointer as a class field, it
> should be passed as raw pointer until it reaches this precise code, where a shared pointer can be created (this again thanks to the
> fact that the reference counter resides on the object and not on the shared pointer).
> This is because, following the second point, we already have a shared pointer
> holding the raw pointer, and passing this down the stack is unneeded since the first shared pointer will be kept alive until the
> execution goes back up the stack.
> 
> For the third one, if one is really unsure about some object lifetime that is used by a thread, then it can be passed or acquired once
> as a shared pointer during the life of the thread.
> I said once, but clearly it depends on how is the scope of that shared pointer (again if you have to pass it down it shouldn't be
> needed to use a shared pointer).
> 
> i know this is a long mail, so take your time, but i'm quite sure that changing how shared pointers are used in Krita will lead to...
> tons of crashes! Ok joking aside, it leads to easier to understand and debug code, it will fix (or expose) hidden architecture issues
> that may lead to crashes, but earlier, and also increase the program efficiency.
> What do you think?

Well, I do agree, up to a point. The thing is, this over-use of shared 
pointers is something we've had since before even I got involved with 
Krita. One of the oldest kdelibs bugs is a wish from the previous krita 
maintainer to improve the shared pointers in kdelibs, and since that 
didn't happen, Cyrille created our own.

What I think would be a good thing to do is this: either for a single 
instance of a shared pointer (like the image's root layer) or for a single 
type of shared pointer, create a proposal with a patch to improve that 
single issue. Then we can check what happens and see how to fix the rest 
of Krita.

Boudewijn