Closed Bug 1873295 Opened 1 year ago Closed 1 year ago

Relax Shmem DEBUG behaviour around actor destruction

Categories

(Core :: IPC, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
124 Branch
Tracking Status
firefox124 --- fixed

People

(Reporter: nika, Assigned: nika)

Details

Attachments

(2 files)

Currently when in a DEBUG build, Shmem has a bunch of extra behaviour and checks, which can occasionally make it more difficult to use. This bug is to track removing some of the unnecessary checks being performed which can make the type more complex to use safely.

Specifically, when the Shmem is destroyed at the actor level using IPrococol::DeallocShmem or because the actor has died, in DEBUG builds the memory mapping used by the Shmem is immediately mapped as non-readable and non-writable. As this can happen at any time, this can make using one of these Shmems from a different thread than the actor it was originally bound to quite difficult. As an example, in bug 1812498, special logic was added to VideoBridgeParent::OnChannelError to block the actor's thread until off-thread uses of the Shmem were complete.

This behaviour was always debug-only, and is actually unnecessary. The actual Shmem mapping is not managed by the actor, only the ability to send it between processes, so it should be reasonable for one of these objects to be used after the actor it was sent over is destroyed. This patch does not change the behaviour of mapping the shared memory pages as inaccessible for non-unsafe shmems while they are "owned" by another process.

We may want to change the name "DeallocShmem" to be something more representative of the true behaviour of the function (which is to prevent further sending of the Shmem object over IPDL, freeing IPDL's reference to the underlying shared memory segment).

Currently when in a DEBUG build, Shmem has a bunch of extra behaviour
and checks, which can occasionally make it more difficult to use. This
bug is to track removing some of the unnecessary checks being performed
which can make the type more complex to use safely.

Specifically, when the Shmem is destroyed at the actor level using
IPrococol::DeallocShmem or because the actor has died, in DEBUG builds
the memory mapping used by the Shmem is immediately mapped as
non-readable and non-writable. As this can happen at any time, this can
make using one of these Shmems from a different thread than the actor it
was originally bound to quite difficult. As an example, in bug 1812498,
special logic was added to VideoBridgeParent::OnChannelError to block
the actor's thread until off-thread uses of the Shmem were complete.

This behaviour was always debug-only, and is actually unnecessary. The
actual Shmem mapping is not managed by the actor, only the ability to
send it between processes, so it should be reasonable for one of these
objects to be used after the actor it was sent over is destroyed. This
patch does not change the behaviour of mapping the shared memory pages
as inaccessible for non-unsafe shmems while they are "owned" by another
process.

In the future, we may want to change the name "DeallocShmem" to be
something more representative of the true behaviour of the function
(which is to prevent further sending of the Shmem object over IPDL,
freeing IPDL's reference to the underlying shared memory segment).

Attachment #9371383 - Attachment description: Bug 1873295 - Relax Shmem DEBUG behaviour around actor destruction, r=#ipc-reviewers! → Bug 1873295 - Part 1: Relax Shmem DEBUG behaviour around actor destruction, r=#ipc-reviewers!

This was added in bug 1812498, but should no longer be necessary after the
changes in part 1, which avoids unnecessary read-protecting Shmem data in debug
builds during IPDL actor destruction.

Depends on D197828

Pushed by nlayzell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e067e965bf17 Part 1: Relax Shmem DEBUG behaviour around actor destruction, r=ipc-reviewers,jld https://hg.mozilla.org/integration/autoland/rev/9559ddacce7e Part 2: Eliminate VideoBridgeParent::OnChannelError, r=sotaro
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 124 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: