Quoting Andreas Rheinhardt (2023-09-19 21:57:09) > Very similar to the AVBufferPool API, but with some differences: > 1. Reusing an already existing entry does not incur an allocation > at all any more (the AVBufferPool API needs to allocate an AVBufferRef). > 2. The tasks done while holding the lock are smaller; e.g. > allocating new entries is now performed without holding the lock. > The same goes for freeing. > 3. The entries are freed as soon as possible (the AVBufferPool API > frees them in two batches: The first in av_buffer_pool_uninit() and > the second immediately before the pool is freed when the last > outstanding entry is returned to the pool). > 4. The API is designed for objects and not naked buffers and > therefore has a reset callback. This is called whenever an object > is returned to the pool. > 5. Just like with the RefStruct API, custom allocators are not > supported. > > (If desired, the FFRefStructPool struct itself could be made > reference counted via the RefStruct API; an FFRefStructPool > would then be freed via ff_refstruct_unref().)
Considering that it's intended to be used from multiple threads, that seems like the better option. Though I have not seen the following patches yet, so maybe the advantage is not as big as I'd think. > +/** > + * If this flag is not set, every object in the pool will be zeroed before > + * the init callback is called or before it is turned over to the user > + * for the first time if no init callback has been provided. > + */ > +#define FF_REFSTRUCT_POOL_FLAG_NO_ZEROING > FF_REFSTRUCT_FLAG_NO_ZEROING Do you think using the same namespace really improves things? It does not seem so to me. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
