mirrors/electron
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions 1

feat: add ipcRenderer.invoke() (#18449)

Browse source
This commit is contained in:
Jeremy Apthorp 2019-05-31 10:25:19 -07:00 • committed by GitHub
parent b180fb376c
commit c436997840
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
17 changed files with 389 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

74
atom/renderer/api/atom_api_renderer_ipc.cc
View file

@ -8,6 +8,7 @@
#include "atom/common/native_mate_converters/value_converter.h"
#include "atom/common/node_bindings.h"
#include "atom/common/node_includes.h"
#include "atom/common/promise_util.h"
#include "base/task/post_task.h"
#include "base/values.h"
#include "content/public/renderer/render_frame.h"
@ -41,6 +42,8 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
DCHECK(render_frame);
render_frame->GetRemoteInterfaces()->GetInterface(
mojo::MakeRequest(&electron_browser_ptr_));
render_frame->GetRemoteInterfaces()->GetInterface(
mojo::MakeRequest(&electron_browser_sync_ptr_));
}
static void BuildPrototype(v8::Isolate* isolate,
v8::Local<v8::FunctionTemplate> prototype) {
@ -49,7 +52,8 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
.SetMethod("send", &IPCRenderer::Send)
.SetMethod("sendSync", &IPCRenderer::SendSync)
.SetMethod("sendTo", &IPCRenderer::SendTo)
.SetMethod("sendToHost", &IPCRenderer::SendToHost);
.SetMethod("sendToHost", &IPCRenderer::SendToHost)
.SetMethod("invoke", &IPCRenderer::Invoke);
}
static mate::Handle<IPCRenderer> Create(v8::Isolate* isolate) {
return mate::CreateHandle(isolate, new IPCRenderer(isolate));
@ -62,6 +66,20 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
electron_browser_ptr_->Message(internal, channel, arguments.Clone());
}
v8::Local<v8::Promise> Invoke(mate::Arguments* args,
const std::string& channel,
const base::Value& arguments) {
atom::util::Promise p(args->isolate());
auto handle = p.GetHandle();
electron_browser_ptr_->Invoke(
channel, arguments.Clone(),
base::BindOnce(
[](atom::util::Promise p, base::Value value) { p.Resolve(value); },
std::move(p)));
return handle;
}
void SendTo(mate::Arguments* args,
bool internal,
bool send_to_all,
@ -82,6 +100,52 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
bool internal,
const std::string& channel,
const base::ListValue& arguments) {
// We aren't using a true synchronous mojo call here. We're calling an
// asynchronous method and blocking on the result. The reason we're doing
// this is a little complicated, so buckle up.
//
// Mojo has a concept of synchronous calls. However, synchronous calls are
// dangerous. In particular, it's quite possible for two processes to call
// synchronous methods on each other and cause a deadlock. Mojo has a
// mechanism to avoid this kind of deadlock: if a process is waiting on the
// result of a synchronous call, and it receives an incoming call for a
// synchronous method, it will process that request immediately, even
// though it's currently blocking. However, if it receives an incoming
// request for an _asynchronous_ method, that can't cause a deadlock, so it
// stashes the request on a queue to be processed once the synchronous
// thing it's waiting on returns.
//
// This behavior is useful for preventing deadlocks, but it is inconvenient
// here because it can result in messages being reordered. If the main
// process is awaiting the result of a synchronous call (which it does only
// very rarely, since it's bad to block the main process), and we send
// first an asynchronous message to the main process, followed by a
// synchronous message, then the main process will process the synchronous
// one first.
//
// It turns out, Electron has some dependency on message ordering,
// especially during window shutdown, and getting messages out of order can
// result in, for example, remote objects disappearing unexpectedly. To
// avoid these issues and guarantee consistent message ordering, we send
// all messages to the main process as asynchronous messages. This causes
// them to always be queued and processed in the same order they were
// received, even if they were received while the main process was waiting
// on a synchronous call.
//
// However, in the calling process, we still need to block on the result,
// because the caller is expecting a result synchronously. So we do a bit
// of a trick: we pass the Mojo handle over to a new thread, send the
// asynchronous message from that thread, and then block on the result.
// It's important that we pass the handle over to the new thread, because
// that allows Mojo to process incoming messages (most importantly, the
// response to our request) on the new thread. If we didn't pass it to a
// new thread, and instead sent the call from the main thread, we would
// never receive a response because Mojo wouldn't be able to run its
// message handling code, because the main thread would be tied up blocking
// on the WaitableEvent.
//
// Phew. If you got this far, here's a gold star: ⭐️
base::Value result;
// A task is posted to a separate thread to execute the request so that
@ -96,7 +160,7 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
// We unbind the interface from this thread to pass it over to the worker
// thread temporarily. This requires that no callbacks be pending for this
// interface.
auto interface_info = electron_browser_ptr_.PassInterface();
auto interface_info = electron_browser_sync_ptr_.PassInterface();
task_runner->PostTask(
FROM_HERE, base::BindOnce(&IPCRenderer::SendMessageSyncOnWorkerThread,
base::Unretained(&interface_info),
@ -104,7 +168,7 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
base::Unretained(&result), internal, channel,
base::Unretained(&arguments)));
response_received_event.Wait();
electron_browser_ptr_.Bind(std::move(interface_info));
electron_browser_sync_ptr_.Bind(std::move(interface_info));
return result;
}
@ -135,6 +199,10 @@ class IPCRenderer : public mate::Wrappable<IPCRenderer> {
}
atom::mojom::ElectronBrowserPtr electron_browser_ptr_;
// We execute all synchronous calls on a separate mojo pipe, because
// of the way that we block on the result of synchronous calls.
atom::mojom::ElectronBrowserPtr electron_browser_sync_ptr_;
};
void Initialize(v8::Local<v8::Object> exports,