[vlc-devel] [vlc-commits] Use str_format_meta for snapshots

Rafaël Carré funman at videolan.org
Fri Jan 17 08:35:07 CET 2014


On 01/17/14 08:32, Rémi Denis-Courmont wrote:
> On Fri, 17 Jan 2014 08:25:44 +0100, Rafaël Carré <funman at videolan.org>
> wrote:
>> On 01/17/14 03:15, Rémi Denis-Courmont wrote:
>>> On Thu, 16 Jan 2014 22:01:12 +0100 (CET), git at videolan.org (Rafaël
>>> Carré)
>>> wrote:
>>>> vlc | branch: master | Rafaël Carré <funman at videolan.org> | Thu Jan 16
>>>> 22:00:52 2014 +0100| [17818d7bce710b281bc9d012aaf84a18b59924e2] |
>>>> committer: Rafaël Carré
>>>>
>>>> Use str_format_meta for snapshots
>>>
>>> The vout outlives the subsequent inputs, so this is obviously invalid.
>>> The
>>> pointer is potentially dangling there.
>>
>> The vout indeed survives subsequent inputs but its configuration is
>> updated (see vout_Request) so vout->p->input should stay valid.
> 
> Of course not. First that does not solve the synchronization of memory
> access to the pointer. 

That's true but that is not the issue you pointed out.

> Second, there is intrinsically a window of time when
> the input is invalid; since there is a window of time when there is no
> input at all.

As I said since the update is done by the input itself there is no such
window.

> (And last, the current code with pointer comparison is even
> flaky, since the "new" input could have the same address as the "old"
> input, and yet they would be different input instances; but at least that
> is not a race unlike your patch.)

True but since input deattaches itself from vout I don't see how it can
have any other values than NULL or current input.

>> Sorry but I am not convinced this should be removed, as far as I can
>> tell the vout references the input properly.
> 
> It looks more like you are (again) defending a ridiculous side of an
> argument for the sake of having an argument.

Sorry but no.



More information about the vlc-devel mailing list