On 5/28/21 12:09 PM, Giovanni Mascellani wrote:
Hi,
Il 28/05/21 10:32, Nikolay Sivov ha scritto:
I don't think we want that, it's blocking, so can potentially hang the test program, and you won't know where that happened.
So what should the test do? Implement a timeout? We cannot just assume that the event will be delivered immediately.
For GetEvent() you'll need to call it with no-wait flag several times to implement such timeout. Async event delivery is causing troubles too, as mfplat/tests demonstrate (at least on Win7 that we still use).
+ for (i = 0; i < 4; i++) + expect_event(stream, MEStreamSinkRequestSample); + expect_event(stream, MEStreamSinkStarted);
Same here, the test only cares for state changes, and checking for everything exposes this improvised on-start prerolling.
That's curious, because on Windows the test passes on basically all versions (except some segmentation faults with Win 7, but I think that is a separate issue, given that I was hitting it also with another patch set), so I thought that four was considered a consistent constant of Windows and that we wanted to emulate it.
What would you expect here? I just check that at least on MEStreamSinkRequestSample event is generated? Or I just ignore any generated MEStreamSinkReuqestSample event until I get the MEStreamSinkStarted?
I don't think we need event tests at all for this case, it's already clear where state change happens, and that pause is not triggered.
Thanks, Giovanni.