Memory sharing between browser / renderer contexts


It is really frustrating when ‘obvious’ questions are not answered in documentation, or are answered so elliptically as to be useless. Here is what I think is true about atom-shell apps:

  1. data memory is not shared between any processes (no JS variables in common)

  2. node module loads are not shared between any processes

  3. the only data sharing mechanism between processes is via IPC

If these are not true, where does it say so clearly? If these are true, why don’t the docs say so clearly and ‘obviously’?


I just went to the atom-shell github repo page, and in the readme I found the documentation link. The documentation had a couple of other links, and the quick start seemed to be the most promising first document. So I go to the quick start and then I find this:

Differences between main process and renderer process

The main process creates web pages by creating BrowserWindow instances, and each BrowserWindow instance runs the web page in its own renderer process, when a BrowserWindow instance is destroyed, the corresponding renderer process would also be terminated.

So the main process manages all web pages and their corresponding renderer processes, and each renderer process is separated from each other and only care about the web page running in it.

In web pages it is not allowed call native GUI related APIs because managing native GUI resources in web pages is very dangerous and easy to leak resources. If you want to do GUI operations in web pages, you have to communicate with the main process to do it there.

In atom-shell, we have provided the ipc module for communication between main process and renderer process. And there is also a remote module for RPC style communication.

I vaguely remembered this must have been described, so I knew it must be there, so it was easier to find.


Um, yes, that talks about the separation of processes and responsibilities. Even more detail is possible following the link from docs/development/source-code-directory-structure to document Chromium’s multi-process architecture.

But… that says very little (nothing) about memory sharing or sharing of data variables.

Which is rather important to my application which will need to share up to 10’s of MB of x0000’s of objects between windows (different visualizations with dynamic in-memory updating).

And why, unless more information is forthcoming, I must use NW.js instead. I’d thought I had options as there were two similar competing browser implementations. (sigh)


Hm. For me, running multiple processes already implies that there is no sharing of variables: This is true for all processes in general. To use a Windows example, that’s why Firefox doesn’t change the text in your Word document – because Firefox and Word are two separate processes, and so Firefox can’t.

And the last paragraph mentiones the ipc module and the remote module for communicating between processes. I don’t know if it’s feasible to transmit tens of MB via ipc. It doesn’t sound too scary – it’s all local after all.

Do you have to use different windows? Can’t it be different tabs in the same window? Or split panes? (Of course you’re doing Atom Shell and thus you have to implement the tabs first.)


In linux and windows you can share memory-maps between processes.

But Mac doesn’t support it. You might fall back to IPC on macs.