On Thu, Jun 06, 2024 at 01:17:48AM +0200, Michael Niedermayer wrote: [...] > AVOption simply provides light weight access to the struct fields. > Calling AVOption non re-entrant in modifying a field you arent even allowed > to modify from 2 threads is confusing
I think you're saying there's already a rule about modifying AVOptions from 2 threads. Could you explain that in more detail? > If you want to modify a field from 2 threads that field could be some sort > of atomic type. This can then easily be added to AVOption Doing that for a single option would involve publicly guaranteeing its representation for at least one major version. At that point, you might as well just tell people to access it as a member of a public struct. To be clear - this isn't a programming problem, it's a design problem. The interface currently allows external developers to assume something will always work when it's actually just something that could be supported some day. Writing up the current behaviour as a guarantee lets them avoid writing code that will generate hard-to-reproduce bugs, at the cost of making it slightly harder for us to do something we've never needed to do in the past. _______________________________________________ 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".
