FrameFactory discussion

[kumaakh]

So I was struggling to understand the intent of this line:

The original idea was the following:

• historically: to avoid memcpy we would makeFrame(size) and use the memory returned as the destination for any imaging operations: worked well when the out memory needed was a of known fixed size, eg. in decompressors (whchans)
• However this is an issue if the output size required is variable, e.g. we can not guess the size of a JPEG Compressed image.
• To solve this issue we wanted to come up with a method where, we make a BigFrame which is big enough to contain the output and write on it from left, naturally and once we know the size, we would split it to make a new left frame as output and the expectation was that the Remaining part of BigFrame will be given back to the pool. This was supposed to be achieved by makeFrame(BigFrame, size).
• How does it work:
  • we are reducing the chunks in use by adjusting the size
  • we are also making sure the the BigFrame is no longer holding memory by the resetMemory() call at this line:

Issues 1
While this explains, it is a bad implementation for the application developer who may end up trying to reuse the BigFrame and get trapped.

A better implementation would be to setup the BigFrame with a new OrigPointer and size and not return the chunks to pool.

Issues 2
Another issue came to highlight is the usage of mutable_buffers increment operarator + viz a viz these lines

What happens when the application developer ever increments frame_sp?

• since Frame is a subclass of mutable_buffer, the increment operator makes a new copy of Frame with Old Orig (due to implicit copy constructor) and new a displaced data pointer and a reduced size()
• this may be problematic because now we have 2 paths to call the same destroy() function potentially leading to some race conditions, need to prove this by a unit test.