From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E038148BC4 for ; Thu, 6 Jun 2024 08:29:42 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D362068D67A; Thu, 6 Jun 2024 11:29:39 +0300 (EEST) Received: from alt2.a-painless.mh.aa.net.uk (alt2.a-painless.mh.aa.net.uk [81.187.30.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id F408A68D628 for ; Thu, 6 Jun 2024 11:29:32 +0300 (EEST) Received: from 0.2.1.4.9.2.b.b.8.4.d.a.9.b.d.6.0.5.8.0.9.1.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:819:850:6db9:ad48:bb29:4120] helo=andrews-2024-laptop.sayers) by painless-a.thn.aa.net.uk with smtp (Exim 4.96) (envelope-from ) id 1sF8V2-00AEiS-0b for ffmpeg-devel@ffmpeg.org; Thu, 06 Jun 2024 09:29:32 +0100 Date: Thu, 6 Jun 2024 09:29:24 +0100 From: Andrew Sayers To: FFmpeg development discussions and patches Message-ID: References: <20240605131808.282394-1-ffmpeg-devel@pileofstuff.org> <20240605231748.GM2821752@pb2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240605231748.GM2821752@pb2> Subject: Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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-request@ffmpeg.org with subject "unsubscribe".