[Webkit-unassigned] [Bug 205460] Update TrackBase to store m_mediaElement as a WeakPtr

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=205460

--- Comment #12 from Darin Adler <darin at apple.com> ---
Comment on attachment 386241
  --> https://bugs.webkit.org/attachment.cgi?id=386241
Patch

OK, now looking at the new patch and thinking about the long term for all of WebKit I think we are still probably doing this wrong. Generally speaking:

- Data members are long lived, so when the object is reference counted they should be WeakPtr, RefPtr, or Ref. It’s important that we use WeakPtr rather than RefPtr or Ref to avoid creating reference cycles and generally to avoid keeping objects alive too long. But we usually don’t want to use raw pointers or raw references because it’s too easy to get it wrong.

- Local variables, arguments, and return values are less long lived. They should probably never be WeakPtr because WeakPtr is too expensive to create and destroy and it’s almost always fine to keep an object alive a little longer by using RefPtr instead. But for safety these should probably be RefPtr or Ref and not raw pointers or raw references.

- It might be safe to sometimes use const& or && to avoid unnecessary copying. However, it may not be worth it. These are a bit dangerous because they depend on the lifetime of the place where the value is coming from. For example, if you return a const& to a data member and then the object it was returned from is deleted then there could be a problem if we still haven’t copied the value out of the referenced location. Not sure if this same argument applies to values passed in.

I am sure we don’t want to create a temporary WeakPtr and then copy it into a permanent WeakPtr. That is excessively inefficient. But I am not sure that WeakPtr&& is right either. What is the right type for arguments in cases like this?

I’d love to just supply the answer, but I am not sure!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191220/d6830819/attachment.htm>