That’s sort of a nit-picky point to make but I think it’s important and knowing it leads to a more solid conceptual foundation.
A renderer process isn’t actually created until a window has a webContents instance in it. I used to conflate a BrowserWindow with a renderer process. All DOM APIs, node.js APIs, and a subset of Electron APIs (see graphic below) are available in the renderer. The render process is responsible for running the user-interface of your app, or in other words, a web page which is an instance of webContents. This is to avoid potential memory leak problems. The docs state: “The basic rule is: if a module is GUI or low-level system related, then it should be only available in the main process.” (Note that GUI here means native GUI, not HTML based UI rendered by Chromium). A subset of Electron APIs (see graphic below) are available in the main process, as well as all node.js modules. Your app’s entry point will point to a JavaScript file that will be executed in the main process. It can also do things like register global shortcuts, create native menus and dialogs, respond to auto-update events, and more. The main process is responsible for creating and managing BrowserWindow instances and various application events. Chromium has pretty interesting documentation on it’s multi-process architecture here: Main process This architecture is to thank for that resilience. In this sense, “Chromium is built like an operating system, using multiple OS processes to isolate web sites from each other and from the browser itself.” So each process “runs in its own address space, is scheduled by the operating system, and can fail independently.” I think we’ve all accidentally written an infinite loop before that brings down the tab it’s running in, but not the entire browser. webContents instance) in a separate process so that if one tab runs into a fatal error, it doesn’t bring down the entire application. This architectural decision originates from Chromium. This might be obvious to some but it wasn’t to me, so there you have it.
There are literally two instances of that module running. The two processes don’t share memory or state. If I increment in my renderer, the count in the renderer will be 1, but it’ll still be 0 in the main process. So for example, let’s say I have a module that holds some state that I require in both my main and renderer process: The most important thing to remember here is that processes’ memory and resources are isolated from each other. “Electron” is the main process, one “Electron Helper” is a GPU process, and the other “Electron Helpers” are renderer processes.Įach of these processes run concurrently to each other. Crystal clear, right? For example, if I start an Electron application and then check the Activity Monitor in macOS, I can see how many processes are associated with that program. I mean an operating system level process, or as Wikipedia puts it “an instance of a computer program that is being executed”.
Why does Electron have this multi-process architecture? What are the responsibilities of the main process? What are the responsibilities of a renderer process? How do we communicate between them? First off, what do you mean “process”? It was definitely a paradigm shift for me initially, and working with multiple processes may mean you make different design choices in your app that you wouldn’t otherwise. Dealing with multiple processes is new territory if you’re coming from browser Javascript land. Central to Electron is the concept of two or more operating system level processes running concurrently - the “main” and “renderer” processes.
0 kommentar(er)
