Closed Bug 1642738 Opened 8 months ago Closed 8 months ago

Make the MessageChannel Send and Call methods take a UniquePtr argument


(Core :: IPC, task, P3)




Tracking Status
firefox79 --- fixed


(Reporter: mccr8, Assigned: mccr8)


(Blocks 1 open bug)



(2 files)

There are a few messages on MessageChannel that could take UniquePtr<Message> arguments.

Note that the ones with replies still take a Message* argument for that, because they work by getting a stack-allocated Message passed in, which is move-assigned into. Honestly it feels like passing in a UniquePtr& would be better, because we're heap allocating the reply message anyways, but changing that would require work at the code gen layer, and I expect the move constructor for Message isn't very expensive.

Blocks: 1642746

I have patches for this. I'm just waiting for a try run to make sure it builds on Windows and in Fuzzing, though I think it shouldn't be an issue.

This fixes the leak of a ShmemCreated in the case where ShareHandle fails.

The reply argument that gets passed in is a stack reference which is move
assigned into, so it doesn't make sense as a unique pointer, although the
code could be restructured to return a freshly allocated object instead.

This mostly just eliminates a spurious round trip from UniquePtr to *
and back. The bulk of the patch is renaming uses of |msg| to |aMsg|.

Pushed by
part 1 - Make the non-reply MessageChannel Send messages take a UniquePtr. r=froydnj
part 2 - Make the message arg to two more MessageChannel send methods into a UniquePtr. r=froydnj
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
You need to log in before you can comment on or make changes to this bug.