[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