DesktopCaptureDevice is not safe for asynchronous DesktopCapturer implementation |
||
Issue descriptionBefore desktop_capture_.reset() has been called, DesktopCapturer is always able to push a callback of OnCaptureResult() in the thread. So in the thread there may be, CaptureFrame() -> Destructor(pushed by StopAndDeAllocate()) -> OnCaptureResult(pushed by CaptureFrame()). We do not have this scenario for now, since all the DesktopCapturer implementations synchronously call OnCaptureResult() in CaptureFrame() function. But as far as we design the interface as this, the consumer should prepare for it.
,
Jan 17 2017
DesktopCaptureDevice is not designed to work for asynchronous DesktopCapturer implementation, so instead of changing its behavior, the if no client_ check in OnCaptureResult() should be removed to avoid confusing.
,
Jan 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c4f77c059dcf999c6411ce18d0312dd8f46774bf commit c4f77c059dcf999c6411ce18d0312dd8f46774bf Author: zijiehe <zijiehe@chromium.org> Date: Wed Jan 18 23:24:33 2017 [DesktopCaptureDevice] Remove the if no client_ check DesktopCaptureDevice is not designed to work with asynchronous implementation of DesktopCapturer. So the if (!client_) check in OnCaptureResult() is not reasonable and confusing. BUG= 681145 Review-Url: https://codereview.chromium.org/2625083006 Cr-Commit-Position: refs/heads/master@{#444541} [modify] https://crrev.com/c4f77c059dcf999c6411ce18d0312dd8f46774bf/content/browser/media/capture/desktop_capture_device.cc
,
Jan 21 2017
It's by design. |
||
►
Sign in to add a comment |
||
Comment 1 by zijiehe@chromium.org
, Jan 13 2017