[Webkit-unassigned] [Bug 220038] Unable to postMessage a WebAssembly module to a worklet

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Chris Dumez <cdumez at apple.com> ---
(In reply to Chris Dumez from comment #11)
> (In reply to Yusuke Suzuki from comment #10)
> > (In reply to Chris Dumez from comment #9)
> > > (In reply to Chris Dumez from comment #8)
> > > > (In reply to Chris Dumez from comment #7)
> > > > > (In reply to Richard Newman from comment #6)
> > > > > > I have not tested iframe messaging.
> > > > > > 
> > > > > > Web worker to page seems to work correctly.
> > > > > 
> > > > > Oh I see. If worker to page works then I would imagine iframe messaging
> > > > > would work too. This must be specific to worklets somehow.
> > > > 
> > > > In SerializedScriptValue:
> > > > 
> > > >                 if (m_context != SerializationContext::WorkerPostMessage) {
> > > >                     code = SerializationReturnCode::DataCloneError;
> > > >                     return true;
> > > >                 }
> > > > 
> > > > When encoding wasm modules. We are likely not using the WorkerPostMessage
> > > > SerializationContext when messaging audio worklets?
> > > 
> > > MessagePort::postMessage() seems to use the default serialization context,
> > > no matter in which context the message port is used:
> > > 
> > > ===
> > > ExceptionOr<void> MessagePort::postMessage(JSC::JSGlobalObject& state,
> > > JSC::JSValue messageValue, PostMessageOptions&& options)
> > > {
> > >     LOG(MessagePorts, "Attempting to post message to port %s (to be received
> > > by port %s)", m_identifier.logString().utf8().data(),
> > > m_remoteIdentifier.logString().utf8().data());
> > > 
> > >     registerLocalActivity();
> > > 
> > >     Vector<RefPtr<MessagePort>> ports;
> > >     auto messageData = SerializedScriptValue::create(state, messageValue,
> > > WTFMove(options.transfer), ports);
> > > ===
> > 
> > I changed it to WorkerPostMessage serialization context, and it didn't work
> > because MessagePort always serialize (via IPC encoder) SerializedScriptValue
> > and deserialized it even though both ports are used by the workers/worklets
> > in the same process.
> > The problem is that we do not support full serialization of
> > WebAssembly.Module.
> > 
> > 1. It becomes super huge size
> > 2. It is really complicated
> > 3. Serialize and deserialize it will double memory size while
> > WebAssembly.Module can be shared between multiple threads safely (it is
> > designed to be a thread-safe).
> > 
> > So, we need a notion of "MessageChannel is not used among different
> > processes", and we should avoid using IPC encoder / decoder to serialize
> > SerializedScriptValue for MessagePort. And I think this is what gecko is
> > doing.
> 
> From MessagePort, you can query identifier() and remoteIdentifier(). Each
> returns a MessagePortIdentifier which is a struct that contains both a
> processIdentifier and a portIdentifier. It should therefore be trivial to
> figure out if the local and remote ports are hosted in the same process
> check comparing identifier().processIdentifier and
> remoteIdentifier().processIdentifier.

Indeed, it seems we are going to the NetworkProcess via IPC even though the source and destination processes are identical. This is definitely suboptimal in general and breaking for Wasm modules since those are currently not IPC-encoded.

-- 
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/20210114/4183e287/attachment.htm>