Text edits on remote
This commit is contained in:
parent
e6e09a8a7c
commit
2ead38b03f
1 changed files with 11 additions and 9 deletions
|
@ -6,7 +6,7 @@ between the renderer process (web page) and the main process.
|
||||||
In Electron, only GUI-unrelated modules are available in the renderer process.
|
In Electron, only GUI-unrelated modules are available in the renderer process.
|
||||||
Without the `remote` module, users who want to call a main process API in
|
Without the `remote` module, users who want to call a main process API in
|
||||||
the renderer process would have to explicitly send inter-process messages
|
the renderer process would have to explicitly send inter-process messages
|
||||||
to the main process. With the `remote` module, users can invoke methods of the
|
to the main process. With the `remote` module, you can invoke methods of the
|
||||||
main process object without explicitly sending inter-process messages, similar
|
main process object without explicitly sending inter-process messages, similar
|
||||||
to Java's [RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation).
|
to Java's [RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation).
|
||||||
|
|
||||||
|
@ -32,15 +32,16 @@ a new object with the remote constructor (function), you are actually sending
|
||||||
synchronous inter-process messages.
|
synchronous inter-process messages.
|
||||||
|
|
||||||
In the example above, both `BrowserWindow` and `win` were remote objects and
|
In the example above, both `BrowserWindow` and `win` were remote objects and
|
||||||
`new BrowserWindow` didn't create a `BrowserWindow` object in the renderer process.
|
`new BrowserWindow` didn't create a `BrowserWindow` object in the renderer
|
||||||
Instead, it created a `BrowserWindow` object in the main process and returned the
|
process. Instead, it created a `BrowserWindow` object in the main process and
|
||||||
corresponding remote object in the renderer process, namely the `win` object.
|
returned the corresponding remote object in the renderer process, namely the
|
||||||
|
`win` object.
|
||||||
|
|
||||||
## Lifetime of Remote Objects
|
## Lifetime of Remote Objects
|
||||||
|
|
||||||
Electron makes sure that as long as the remote object in the renderer process
|
Electron makes sure that as long as the remote object in the renderer process
|
||||||
lives (in other words, has not been garbage collected), the corresponding object
|
lives (in other words, has not been garbage collected), the corresponding object
|
||||||
in the main process will never be released. When the remote object has been
|
in the main process will not be released. When the remote object has been
|
||||||
garbage collected, the corresponding object in the main process will be
|
garbage collected, the corresponding object in the main process will be
|
||||||
dereferenced.
|
dereferenced.
|
||||||
|
|
||||||
|
@ -53,7 +54,8 @@ Primary value types like strings and numbers, however, are sent by copy.
|
||||||
## Passing callbacks to the main process
|
## Passing callbacks to the main process
|
||||||
|
|
||||||
Code in the main process can accept callbacks from the renderer - for instance
|
Code in the main process can accept callbacks from the renderer - for instance
|
||||||
the `remote` module - but you should be extremely careful when using this feature.
|
the `remote` module - but you should be extremely careful when using this
|
||||||
|
feature.
|
||||||
|
|
||||||
First, in order to avoid deadlocks, the callbacks passed to the main process
|
First, in order to avoid deadlocks, the callbacks passed to the main process
|
||||||
are called asynchronously. You should not expect the main process to
|
are called asynchronously. You should not expect the main process to
|
||||||
|
@ -110,9 +112,9 @@ But remember the callback is referenced by the main process until you
|
||||||
explicitly uninstall it. If you do not, each time you reload your window the
|
explicitly uninstall it. If you do not, each time you reload your window the
|
||||||
callback will be installed again, leaking one callback for each restart.
|
callback will be installed again, leaking one callback for each restart.
|
||||||
|
|
||||||
To make things worse, since the context of previously installed callbacks have
|
To make things worse, since the context of previously installed callbacks has
|
||||||
been released, when the `close` event was emitted exceptions will be raised in
|
been released, exceptions will be raised in the main process when the `close`
|
||||||
the main process.
|
event is emitted .
|
||||||
|
|
||||||
To avoid this problem, ensure you clean up any references to renderer callbacks
|
To avoid this problem, ensure you clean up any references to renderer callbacks
|
||||||
passed to the main process. This involves cleaning up event handlers, or
|
passed to the main process. This involves cleaning up event handlers, or
|
||||||
|
|
Loading…
Add table
Reference in a new issue