fyi: nsIPrincipal is now threadsafe

[Nika Layzell]

TL;DR a few hours ago, Bug 1443925 merged into central, making nsIPrincipal safe to use from multiple threads. Most nsIPrincipal APIs are now threadsafe, though you should check the updated documentation in nsIPrincipal.idl for the methods you're interested in (at time of writing searchfox is still updating).

Previously, we would use the PrincipalInfo data structure in order to work with principals objects off-main thread, such as in web workers or on the IPDL background thread.This was inconvenient and created a capability difference between background code and main-thread code which could use the full nsIPrincipal type. Going forward, we should prefer using nsIPrincipal over PrincipalInfo to improve consistency, and get access to more powerful APIs.

Some services which were frequently used with nsIPrincipal, such as the nsIScriptSecurityService, remain main-thread only. If they are required off-main-thread they will need to be made threadsafe separately.

As this thread-safety support is new, it is unfortunately likely you will run into roadblocks when migrating code over to using it. Please file bugs for any issues of that kind going forward.

-nika

[Valentin Gosu]

Great work, Nika!

This is a major step forward and removes a big roadblock for moving more things off the main thread.

Thank you!

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CACwGqKikQUPRta6eHhAdztWgXn3vwaG08T7M_1a3Uvd1qrsCCA%40mail.gmail.com.

[Andrew Sutherland]

On 12/2/22 11:34 AM, Nika Layzell wrote:

TL;DR a few hours ago, Bug 1443925 merged into central, making nsIPrincipal safe to use from multiple threads. Most nsIPrincipal APIs are now threadsafe, though you should check the updated documentation in nsIPrincipal.idl for the methods you're interested in (at time of writing searchfox is still updating).

Woooooooooooooooo!

Thank you so much for all your work on this major undertaking, both on the recent bug and all of the heavy lifting that went into this in previous bugs through the years.  This will enable major cleanups throughout both the dom/workers/ code as well as all of the code that runs on top of workers that will significantly reduce complexity and meaningfully improve performance by eliminating jank!

A hearty thank you as well to everyone who had a part in making this possible!  It's been a long journey from the world of legacy extensions when JS could (and did!) implement anything and everything... nsIPrincipal only was marked builtinclass[0] in 2012 by jlebar[1] and nsIURI in 2017 by Valentin[2], with Valentin making NS_NewURI work off the main thread in 2019[3]!

(A very happy) Andrew

0: https://firefox-source-docs.mozilla.org/xpcom/xpidl.html#builtinclass

1: https://hg.mozilla.org/mozilla-central/rev/212e1383eb6ed9d9f6c13530e320bc65815501aa in https://bugzilla.mozilla.org/show_bug.cgi?id=802366

2: https://hg.mozilla.org/mozilla-central/rev/5fcc3fb66b12a4544ba369a9c3b2118a9c3a067f in https://bugzilla.mozilla.org/show_bug.cgi?id=1416343

3: https://bugzilla.mozilla.org/show_bug.cgi?id=1536744 being the last bug that allowed OMT-nsURI https://bugzilla.mozilla.org/show_bug.cgi?id=922464 to be closed, resulting in the https://groups.google.com/g/mozilla.dev.platform/c/ILkf8vTRZsI victory message.