[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 2/2] strmbase: Reset the renderer's state event when flushing.
From:       Gabriel_Ivăncescu <gabrielopcode () gmail ! com>
Date:       2022-09-26 13:06:14
Message-ID: 984c83ce-5191-d1af-9bbb-ffc5c7947d50 () gmail ! com
[Download RAW message or body]

On 16/11/2020 23:07, Zebediah Figura (she/her) wrote:
> On 11/3/20 6:43 AM, Gabriel Ivăncescu wrote:
>> On 02/11/2020 20:11, Zebediah Figura wrote:
>>> This patch isn't wrong per se, but it's less pretty than it could be,
>>> and exposes some of the still-present problems with renderer locking.
>>> Sorry, I'll need more than a little time to review this.
>>>
>>
>> Understood. Only thing is that I won't be able to send a new version of
>> the media detector patches until then, though, because it depends on it.
>> (that is why I haven't)
>>
> 
> For the sake of transparency, the basic problem is that this patch
> treats "filter->sink.flushing" as protected by "csRenderLock", when in
> fact it's not. The lock taken in sink_begin_flush() *does* prevent the
> race you describe, but it does so in a very non-obvious way. I'm
> currently working on restructuring some things so that "flushing" is
> protected by a lock which we can safely take from the streaming thread,
> but it may take a while (and may not make it in by code freeze).
> 

Hi Zeb,

Sorry if this is already done, but I was going through some of my stuff, 
it seems I still need this patch to have those tests work (and 
subsequently the other things in qedit). I've no idea how hard this 
would be to restructure properly, so maybe it's already in progress or 
done in some way, but if not it's probably just a reminder.

Or if there's a better way now to fix it then please let me know.



[prev in list] [next in list] [prev in thread] [next in thread]