[FFmpeg-devel] [PATCH 17/42] avcodec/refstruct: Add RefStruct pool API

Anton Khirnov anton at khirnov.net
Wed Oct 4 11:39:27 EEST 2023


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


More information about the ffmpeg-devel mailing list