[webkit-reviews] review granted: [Bug 226672] Reduce use of legacy MainThreadTaskQueue in media code : [Attachment 430639] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jun 4 21:14:48 PDT 2021
Darin Adler <darin at apple.com> has granted Chris Dumez <cdumez at apple.com>'s
request for review:
Bug 226672: Reduce use of legacy MainThreadTaskQueue in media code
https://bugs.webkit.org/show_bug.cgi?id=226672
Attachment 430639: Patch
https://bugs.webkit.org/attachment.cgi?id=430639&action=review
--- Comment #2 from Darin Adler <darin at apple.com> ---
Comment on attachment 430639
--> https://bugs.webkit.org/attachment.cgi?id=430639
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=430639&action=review
> Source/WebCore/platform/graphics/cocoa/TextTrackRepresentationCocoa.mm:155
> + if (weakThis)
> +
weakThis->client().textTrackRepresentationBoundsChanged(weakThis->bounds());
Is bounds() guaranteed to not do any work that could have the side effect of
destroying this?
> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp:182
> + callOnMainThread([this] {
How did you decide a smart pointer (weak pointer or strong pointer) was not
needed here?
> Source/WebCore/platform/mock/MediaPlaybackTargetPickerMock.cpp:79
> + callOnMainThread([this, weakThis = makeWeakPtr(*this)] {
> + if (!weakThis)
> + return;
I prefer the style where we turn weakThis into a RefPtr for the duration of the
lambda over the more tricky style where we capture this twice, for both weak
and strong pointers. And this is test code so it’s not performance-sensitive.
More information about the webkit-reviews
mailing list