Re: Why do the Blink mojo types exist?

[Daniel Cheng]

Historically, Blink didn't do any IPC and had to delegate to the embedder (e.g. //content) to make IPCs on its behalf. However, this means that everything had to be plumbed through the Blink public API layer, which generally resulted in lots of copies (e.g. WTF::String -> WebString (this is cheap) -> std::string (this is expensive)) or std::vector -> WebVector (expensive, is a copy).

With Mojo, we allowed Blink to make IPCs directly/ .To facilitate Blink's usage of Mojo IPC, Mojo generates an additional type variant that use Blink types (WTF::String, WTF::Vector, and WTF::HashMap) instead of STL types. This allows us to save a copy, which is nice.

Unfortunately, there are some downsides:

- There is no easy way to convert from a regular variant struct to a Blink variant struct. (Usually I recommend using a shared typemap in that case, but that generally means using STL types in Blink too)

- Common code to operate on Mojo types generally operates only on the regular variant, so we also allowlist certain things. This is pretty common with the //net types.

- The semantics on both sides don't quite match. For example, the Mojo map<> type is an ordered base::flat_map in the regular variants, but an unordered WTF::HashMap in the Blink variants.

I am not sure what the best path forward here is. It is definitely nice to deserialize directly to the correct types where possible though...

Daniel

On Mon, 3 Jun 2024 at 12:41, Elly <elly...@chromium.org> wrote:

This question is inspired by https://issues.chromium.org/issues/341991525.

Why do we have the Blink-specific types? Should we still have them?

-- elly

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/693c111c-89e4-4841-b7eb-8049a5f0c154n%40chromium.org.

[Matt Denton]

On Mon, Jun 3, 2024 at 1:25 PM Daniel Cheng <dch...@chromium.org> wrote:

Historically, Blink didn't do any IPC and had to delegate to the embedder (e.g. //content) to make IPCs on its behalf. However, this means that everything had to be plumbed through the Blink public API layer, which generally resulted in lots of copies (e.g. WTF::String -> WebString (this is cheap) -> std::string (this is expensive)) or std::vector -> WebVector (expensive, is a copy).

With Mojo, we allowed Blink to make IPCs directly/ .To facilitate Blink's usage of Mojo IPC, Mojo generates an additional type variant that use Blink types (WTF::String, WTF::Vector, and WTF::HashMap) instead of STL types. This allows us to save a copy, which is nice.

Unfortunately, there are some downsides:

- There is no easy way to convert from a regular variant struct to a Blink variant struct. (Usually I recommend using a shared typemap in that case, but that generally means using STL types in Blink too)

- Common code to operate on Mojo types generally operates only on the regular variant, so we also allowlist certain things. This is pretty common with the //net types.

- The semantics on both sides don't quite match. For example, the Mojo map<> type is an ordered base::flat_map in the regular variants, but an unordered WTF::HashMap in the Blink variants.

One time I wanted to use a map<network.mojom.IPAddress, SomeStruct> in a mojo method. I didn't want to use the blink variant but I couldn't really avoid generating the blink variant, which meant I ended up having to write a bunch of blink HashTraits for net::IPAddress. That felt like a downside as well.

 

I am not sure what the best path forward here is. It is definitely nice to deserialize directly to the correct types where possible though...

Daniel

On Mon, 3 Jun 2024 at 12:41, Elly <elly...@chromium.org> wrote:

This question is inspired by https://issues.chromium.org/issues/341991525.

Why do we have the Blink-specific types? Should we still have them?

-- elly

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/693c111c-89e4-4841-b7eb-8049a5f0c154n%40chromium.org.

--

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

[Jeremy Roman]

And Blink's use of bespoke types internally has decreased, but remains. std::string isn't a good (or at least, drop-in) replacement for WTF::String in Blink for a number of reasons related to JavaScript and the web platform (an old internal talk, go/jbroman-wtf-string, talks a bit about why strings are more complicated than they seem), and some of the container types have historically had better performance for some key use cases (at least, that was the common wisdom -- this could always have evolved) and also garbage collection integration (which, again, is often useful for interacting with JavaScript/DOM code which is naturally GCed). Strings are probably the stickier of the two from an IPC POV.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKr%2BgfmphX0%3DDvDegMvbgFMzzTYmZF8uonJyJXAFaNCb2A%40mail.gmail.com.