Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant
Date: Thu, 6 Jun 2024 16:24:11 +0200
Message-ID: <20240606142411.GO2821752@pb2> (raw)
In-Reply-To: <ZmFzY9RxbuEHhu9V@andrews-2024-laptop.sayers>

[-- Attachment #1.1: Type: text/plain, Size: 1971 bytes --]

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

> 
> > 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.

A feature can be added at any time without a major version bump
adding an option that uses a atomic type can thus also be done at any time

It can be possible to transparenntly change the underlaying representation
under an AVOption without ABI break but that requires some thought and care

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".