From: "Zebediah Figura (she/her)" Subject: Re: [PATCH 2/2] strmbase: Reset the renderer's state event when flushing. Message-Id: <9d0c2229-b239-d566-d401-0fe105317290@codeweavers.com> Date: Mon, 16 Nov 2020 15:07:03 -0600 In-Reply-To: <5ab59dc7-fba3-23be-a042-08379d98ffcb@gmail.com> References: <5def2d7ec5f6cc93efb5266853c21cc81501ba4b.1603818649.git.gabrielopcode@gmail.com> <73a6cd2b81b573add86796c5e40daa01a5b3b9c1.1603818649.git.gabrielopcode@gmail.com> <53c0fe02-f241-86f9-72c3-fb1ed2b14b07@gmail.com> <5ab59dc7-fba3-23be-a042-08379d98ffcb@gmail.com> 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). -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENTo75Twe9rbPART3DZ01igeheEAFAl+y6fcACgkQDZ01igeh eEAt2wf5AVsd175B2adTDJgIWpBd4aJ+xg0ZhqXTvISFjPHZuo3oG2x8XYCt/HrS feEUZQrLPNRYxlNBGJ9mCjpFqC0O2XbypeuXEzClgO+sg0kJz2F4rq1SYaH625ES DPqaops78uMXKe0+GK5C/x4DtnXfQmT20tZt2L5rJItZa5aM4csPu4If0ECLGkex 1OjbzCWJ0QGITdsVWCkjPW08xC+sOhW5di1pMJo7t1j0ae2yM/agF6mVkAijxlN1 Xt6/9tO0MxLx7H7qhuQ4PhEn63C4qpimnrEWbuACNyOfEPGFvX0ETgkNTpFUqCtX /ZP3NKS/JcLZz9mTZYkUHmGOX4dTxg== =mndr -----END PGP SIGNATURE-----