[webkit-reviews] review denied: [Bug 236558] [GStreamer] Initial MediaRecorder implementation : [Attachment 451896] Patch

[bugzilla-daemon at webkit.org]

Xabier Rodríguez Calvar <calvaris at igalia.com> has denied Philippe Normand
<pnormand at igalia.com>'s request for review:
Bug 236558: [GStreamer] Initial MediaRecorder implementation
https://bugs.webkit.org/show_bug.cgi?id=236558

Attachment 451896: Patch

https://bugs.webkit.org/attachment.cgi?id=451896&action=review




--- Comment #7 from Xabier Rodríguez Calvar <calvaris at igalia.com> ---
Comment on attachment 451896
  --> https://bugs.webkit.org/attachment.cgi?id=451896
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=451896&action=review

Would be interesting to honor what Eric is saying.

> Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:85
> +    auto scopeExit = makeScopeExit([this, weakThis = WeakPtr { this },
completionHandler = WTFMove(completionHandler)]() mutable {

Interesting to see creating a WeakPtr for a scope exit. Can this really happen?
Can this object be destroyed while executing this method? If this can happen I
would be even more worried about accessing the other attributes, like m_eos,
m_eosLock, etc. If this is so, then I guess what we should do is doing a hard
ref and making up some invalidation system or at least locking in the
destructor. Calling this method on a dead object would be the worst scenario,
obviously.

> Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:110
> +    bool isEOS = false;
> +    {
> +	   LockHolder lock(m_eosLock);
> +	   isEOS = m_eos;
> +    }
> +    while (!isEOS) {
> +	   LockHolder lock(m_eosLock);
> +	   m_eosCondition.waitFor(m_eosLock, 200_ms, [weakThis = WeakPtr { this
}]() -> bool {

I don't think you need to do this because the waitFor checks the predicate
before waiting.

>
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:19
8
> +	   callOnMainThread([&] {
> +	       if (m_track.hasAudio())
> +		   m_track.source().removeAudioSampleObserver(*this);
> +	       else if (m_track.hasVideo())
> +		   m_track.source().removeVideoSampleObserver(*this);
> +	       m_track.removeObserver(*this);
> +	   });

Nope! You call this from the destructor, deferring this to the main thread
would mean you're accessing stuff after the object is destroyed. Maybe AndWait
can help, but this means r- .