[vlc-devel] [RFC-PATCH 04/12] core: introduce input_Decoder{Set, Get}PrerollEnd

[Filip Roséen]

> This smells fishy. Protecting a single store or a single load with a lock 
> makes the memory access atomic, but it does not magically make it correct.
> 
> The lock means you won´t do undefined memory accesses (in theory), and won´t 
> get half-updated values (in practice, on 32-bits platforms). The value itself 
> will still change in fundamentally racy way.
 
Very much agreed! There is an "TODO" attached to the associated message when
sending the patch to the mailing-list:

    TODO: Instead of locking/unlocking the mutex each time we are interested in
    reading/writing the value, we should use an atomic variable.

> I know the problem predates (by very long) this patch. But at least, it is 
> currently contained. I don´t think we should expose a fundamentally broken 
> API.

Yes, and I plan to spend more time working on that at a later time (unless
someone beats me to it). I was focusing on what is practically broken with these
patches, though (as stated) I 100% agree with you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160511/6053787d/attachment.html>