Bug 222701 – Clean up API::ResourceLoadStatisticsThirdParty / API::ResourceLoadStatisticsFirstParty

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Chris Dumez]

Clean up API::ResourceLoadStatisticsThirdParty / API::ResourceLoadStatisticsFirstParty.

[Chris Dumez]

Created attachment 422162 [details]
Patch

[Chris Dumez]

Created attachment 422165 [details]
Patch

[Geoffrey Garen]

Comment on attachment 422165 [details]
Patch

r=me

Maybe we should make this a release assert so we can catch it in CrashTracer.

[Alex Christensen]

I think we need to do something more general.  It should be made always OK to deallocate our ObjC objects on a background thread.

[Chris Dumez]

(In reply to Alex Christensen from comment #4)
> I think we need to do something more general.  It should be made always OK
> to deallocate our ObjC objects on a background thread.

It is a slippery slope. If we start allowing our objects to be destroyed on a background thread, then clients are doing to be tempted to also *USE* these objects on a background thread and our API is currently not thread-safe by any means.

[Chris Dumez]

Created attachment 422282 [details]
Patch

[Geoffrey Garen]

Sometimes it can be hard, especially with ARC, to ensure deallocation on the main thread -- even when there is no use on a secondary thread -- just because of the transitive set of pointers in an object graph. In the past, we have sometimes written code to forward the deallocation of an API object to the main thread if needed. It might be something worth considering from some of our API objects. That said, in the cases we know about right now, the bug appears to be *use* on a secondary thread, and not just deallocation.

[EWS]

Committed r273923: <https://commits.webkit.org/r273923>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 422282 [details].

[Radar WebKit Bug Importer]

<rdar://problem/75059950>

[Chris Dumez]

(In reply to Geoffrey Garen from comment #7)
> Sometimes it can be hard, especially with ARC, to ensure deallocation on the
> main thread -- even when there is no use on a secondary thread -- just
> because of the transitive set of pointers in an object graph. In the past,
> we have sometimes written code to forward the deallocation of an API object
> to the main thread if needed. It might be something worth considering from
> some of our API objects. That said, in the cases we know about right now,
> the bug appears to be *use* on a secondary thread, and not just deallocation.

I see, then I agree that it may be nice to make our API objects dispatch to main thread on destruction.