[vlc-devel] [PATCH 1/4] filters: flush before closing filters

[Rémi Denis-Courmont]

So what? An asynchronous filter would be able to output until close returns, not until close starts. Also some filters may output some place else (e.g. scene) and distinguish between flush and drain at that level.

You're just making assumptions/restrictions in the core about implementation decisions and details of the filters.

Le 13 octobre 2020 09:49:56 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>On 2020-10-13 8:37, Rémi Denis-Courmont wrote:
>> Hi,
>> 
>> I don't think that's correct. A filter could very well want to drain 
>> rather than flush at close, or whatever. It's no surprise that
>flushing 
>> is often done at close but I don't think it should be forced.
>
>This is a Close call. At this point the filter cannot decide to drain, 
>there's noone left to receive the pictures. On the other hand, if it
>has 
>buffers pending, it MUST release them on Close. It can be done 
>internally or via a global Flush.
>
>> And then it makes reading the code more difficult, as it's nonobvious
>
>> that Flush would be called implicitly at exit. Soon we'd see Close ->
>
>> Flush calls being added again to fix nonexistent leaks.
>
>It's a possibility but it's not a bug and won't cause any problem, just
>
>wasted CPU cycles. Code review or debugging should avoid this in most
>cases.
>
>Having filters with dangling pictures/blocks on Close is totally 
>preventable by making sure we always flush. It also avoids duplicate 
>code in Close when the Flush is already coded. I can see some other 
>filters that could be simplified because of this.
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20201013/39f6848f/attachment.html>