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 4F5BD4A9EC for ; Thu, 6 Jun 2024 15:43:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F004768D6F9; Thu, 6 Jun 2024 18:43:17 +0300 (EEST) Received: from alt2.a-painless.mh.aa.net.uk (unknown [81.187.30.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BA0F368D5F0 for ; Thu, 6 Jun 2024 18:43:11 +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 1sFFGg-00AqGs-1t for ffmpeg-devel@ffmpeg.org; Thu, 06 Jun 2024 16:43:11 +0100 Date: Thu, 6 Jun 2024 16:43:08 +0100 From: Andrew Sayers To: FFmpeg development discussions and patches Message-ID: References: <20240605131808.282394-1-ffmpeg-devel@pileofstuff.org> <20240605231748.GM2821752@pb2> <20240606142411.GO2821752@pb2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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 05:21:00PM +0200, Andreas Rheinhardt wrote: > Andrew Sayers: > > On Thu, Jun 06, 2024 at 04:24:11PM +0200, Michael Niedermayer wrote: > >> On Thu, Jun 06, 2024 at 09:29:24AM +0100, Andrew Sayers wrote: > >>> 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? > >> > >> Well, one way this can be argued is this: > >> Latest C draft: (but i doubt this is different) ISO/IEC 9899:2017 C17 ballot N2176 > >> > >> "Two expression evaluations conflict if one of them modifies a memory location and the other one > >> reads or modifies the same memory location" > >> > >> so if you have 2 threads and one writes into a int and another reads it at the > >> same time, the code is broken. > >> The code doing said act through some API doesnt become less broken > >> > >> Calling AVOption non re-rentrant because of that is false thats as if one executed > >> strtok_r(a,b,c) with the VERY same a,b,c from 2 threads and then said > >> its not thread safe > >> > >> strtok_r() is thread safe and reentrant if its used correctly, so is AVOption > > [...] > > > > Ok, how about if the patch avoided the word "reentrant" and just said: > > > > + * Note: AVOptions values should not be modified after a struct is initialized. > > This is wrong either. As Paul has already pointed out to you, some > options are allowed to be modified lateron. Ah, I'd interpreted "runtime" to be the opposite of "compile-time", not "initialization-time". I'll propose a new patch that should be clearer. _______________________________________________ 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".