Anton Khirnov: > 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. >
It is implemented in patch #24. >> +/** >> + * 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. > Actually, the namespaces are separate. The pool API uses FF_REFSTRUCT_POOL_FLAG_*, the ordinary RefStruct API uses FF_REFSTRUCT_FLAG_*. That some pool flags are simply mapped to non-pool flags is an implementation detail and does not join the namespaces. - Andreas _______________________________________________ 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".