Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: ensure correct ordering of sendSync w.r.t. send #18630

Merged
merged 4 commits into from
Jun 5, 2019
Merged

Conversation

nornagon
Copy link
Member

@nornagon nornagon commented Jun 4, 2019

Description of Change

#18449 introduced a potential race between send and sendSync by pushing sendSync calls to a separate mojo pipe, which is the cause of the recent test flake in remote module tests. This change rearranges the calls so send and family all happen on the same pipe, and only invoke happens on a different pipe, which it must do because it has a callback with a result (which can't be pending when sendSync is called, or else DCHECK). There are no ordering concerns currently w/ invoke because we don't really use it, but in future we probably want to guarantee that send and invoke share an ordering, which will require some further trickery.

Checklist

Release Notes

Notes: no-notes

@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Jun 4, 2019
Copy link
Member

@MarshallOfSound MarshallOfSound left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems legit 👍 🚢

const std::string& channel,
const base::ListValue& arguments) {
electron_browser_ptr_->Message(internal, channel, arguments.Clone());
electron_browser_ptr_->get()->Message(internal, channel, arguments.Clone());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that the interface ptr is created on the background runner, which is a different sequence to that of the main runner. Is it okay to call methods on this ptr in the main sequence without calling PassInterface ? well that would technically create a new pipe which would defeat the purpose. Just to make sure is this a safe operation ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type of this pointer changed to ThreadSafeElectronBrowserPtr, whose raison d'etre is to allow calling methods from multiple threads. This doesn't create any new pipes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay it uses mojo/public/cpp/bindings/thread_safe_interface_ptr.h , wasn't aware of this helper.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't either until I asked in #mojo on the Chromium Slack :)

@deepak1556 deepak1556 requested a review from zcbenz June 4, 2019 23:34
@nornagon
Copy link
Member Author

nornagon commented Jun 5, 2019

I'm merging this ahead of review because it fixes a very annoying flake on master, but I'm happy to incorporate feedback from @zcbenz or anything further from @deepak1556 :)

@nornagon nornagon merged commit 9e8bd43 into master Jun 5, 2019
@release-clerk
Copy link

release-clerk bot commented Jun 5, 2019

No Release Notes

@zcbenz
Copy link
Contributor

zcbenz commented Jun 5, 2019

Edit: this seems to be related to #18555.

Not sure if it is related, but after rebasing to this change, I'm constantly seeing "Object has been destroyed" error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-pr 🌱 PR opened in the last 24 hours
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants