[Webkit-unassigned] [Bug 182496] bmalloc::PerProcess<T> is not really per-process, can lead to mistakes / duplication (IsoTLSDeallocatorEntry<IsoConfig<40u>>)

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Joseph Pecoraro <joepeck at webkit.org> ---
(In reply to Michael Catanzaro from comment #2)
> This is basically identical to bug #179914. I wonder why you never saw
> crashes on Mac. I assumed it wasn't a problem on Mac because you don't use a
> symbol map to hide symbols that would otherwise be exported, but I didn't
> consider that the symbols aren't exported at all.

Whoa! Very interesting, that is exactly what we were seeing.

> PerProcess would be better-named PerLibrary or PerFramework, but that would
> be really terrible because every port makes completely different decisions
> about which WebKit subprojects are built into which shared libraries. It's
> safe to use everywhere on WPE, and at WebCore levels and above for GTK, but
> only in WebKit and WebKitLegacy on Mac; that's way too confusing.

Agreed.


> I guess I don't understand why you created SafePerProcess that works
> properly (good job with that ;) and leaving PerProcess unchanged and broken,
> instead of just fixing PerProcess. The symbols do have to be exported for it
> to work (unless the symbol is used only in the toplevel WebKit subproject).
> So unless you have a better idea, my suggestion is to delete PerProcess,
> rename SafePerProcess to PerProcess, and change all use of PerProcess to use
> DECLARE/DEFINE_SAFE_PER_PROCESS_STORAGE.

The problem with this was that SafePerProcess<T> requires the macro declarations for each of its specializations. For IsoTLSDeallocatorEntry there are currently 53 that are subject to change if the sizeof JavaScriptCore / WebCore classes change, and that list may grow if more types are created. That is unmaintainable for bmalloc to know about all the users outside of it. And I don't know how to create an ideal solution.

The only idea I had was moving off of templates, and moving to singletons / lookups.

-- 
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/20180206/0417ff7c/attachment.html>