2005009 - Add a RemoteObjectHandle abstraction for referencing an object in another process

Status: NEW

(Core :: IPC, enhancement)

Description

[Nika Layzell [:nika] (ni? for response)]

In some cases, it is useful to maintain a reference to a non-transferrable object within a process, such that you can reference it from another process. Doing this manually using a table, and ensuring that the entity is destroyed when the remote process goes away, can be fiddly and requires a good amount of boilerplate.

This patch proposes an abstraction which can be used to handle this situation, using hidden toplevel actors to act as remote reference counts to the underlying types.

I expect that if we get high adoption for this type in the future, we may want to look into further optimizations around the actor overhead for it.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 2005009 - Part 1: Add RemoteObjectHandle helpers, r=#ipc-reviewers!

In some cases, it is useful to maintain a reference to a non-transferrable
object within a process, such that you can reference it from another process.
Doing this manually using a table, and ensuring that the entity is destroyed
when the remote process goes away, can be fiddly and requires a good amount of
boilerplate.

This patch proposes an abstraction which can be used to handle this situation,
using hidden toplevel actors to act as remote reference counts to the
underlying types.

I expect that if we get high adoption for this type in the future, we may want
to look into further optimizations around the actor overhead for it.

Comment 2

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 2005009 - Part 2: Add LazyRemoteObjectHandle, r=#ipc-reviewers!

This is an extension of the RemoteObjectHandle added in part 1 to support cases
where the target object is not synchronously known when creating the handle.

This can be used within a content process when the actual object only exists in
the parent process, with the Pending object passed to the parent process
immediately to be resolved with the remote object. Then, in the future, the
LazyRemoteObjectHandle can be asynchronously queried to the original object
within the parent process.

This currently is primarily intended for use with future Blob URL changes to
represent a resolved Blob URL entry, but may be useful for other components as
well.