New issue
Advanced search Search tips

Issue 710376 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature



Sign in to add a comment

Delete mojo::Un/WrapPlatformFile and mojo::Un/WrapSharedMemoryHandle

Project Member Reported by maxmorin@chromium.org, Apr 11 2017

Issue description

While the documentation of WrapPlatformFile/WrapSharedMemoryHandle states that they take ownership of the passed in handles, this isn't enforced by the compiler. This can lead to double closing if users are careless, see https://codereview.chromium.org/2809673002/ for an example of such a bug. Maybe the ownership should be expressed in the type system somehow (e.g. by using ScopedPlatformHandle).
 
Components: -Internals>Mojo Internals>Mojo>SystemsAPI
Labels: -Pri-3 Pri-2
Status: Available (was: Untriaged)
Summary: Delete mojo::Un/WrapPlatformFile and mojo::Un/WrapSharedMemoryHandle (was: WrapPlatformFile/WrapSharedMemoryHandle isn't foolproof)
Triaging and repurposing this bug with a more appropiate title now. Elevating priority a bit because this would be a nice cleanup and should be fairly straightforward.

We partially addressed this a while ago by deprecating the unsafe APIs in favor of safe ones which pass around single-ownership handle wrappers.

The old APIs still exist but callers can be migrated. Shared memory wrapping may still be a little trickier as there are so many instances of base::SharedMemory usage around the tree still (as opposed to the newer strongly typed scopers like base::ReadOnlySharedMemoryRegion), and that has fundamentally wonky ownership semantics.

Sign in to add a comment