On Wed, 18 Nov 2020, James Almer wrote:
On 11/18/2020 5:08 PM, Marton Balint wrote:
On Wed, 18 Nov 2020, James Almer wrote:
Signed-off-by: James Almer <jamr...@gmail.com>
---
I don't know if this is necessary, so i'm sending it as an RFC.
I don't think this API should provide locking by default, maybe as an
option. But considering that it was not often needed so far, and the API
can be wrapped into locked versions (like decklink does) relatively
easily, I think it is fine as is.
My worry was adding a linked list public API that's not thread safe.
The other example we have is AVBufferPool, which does locking
unconditionally by itself before adding or removing elements from the
list, so it's valid to assume this one should maybe do the same.
AVBufferPool has to be thread safe because the AVBufferRef free function
has to be thread safe as well.
Maybe a better example is av_fifo_generic_read/write which is not thread
safe... Do you know if the overhead of making this thread safe is
significant/measureable? Because obviously that is my primary concern.
Thanks,
Marton
_______________________________________________
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".
